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| am pleased to present the Bureau of Land Management's Eviterprise Architecture, 
Version 2 Summary Report, dated November 2001. This document represents a 
partnered commitment between representatives of our business and technology 
communities within the Bureau of Land Management (BLM). Within this report 
are specific recommendations for improving BLM’s business processes, data and 
automated applications. This report lays the foundation for increased information 
access and sharing resulting in improved services to our internal and external 


customers. 


The Clinger-Cohen Act of 1996 requires Federal Agencies to develop and 
implement information technology architectures that facilitate the delivery of 
information services to the public. As such, the BLM has demonstrated its 
commitment to the fundamentals of this Act by publishing this Second Version of 
our Enterprise Architecture. 


As the Chief Information Officer for BLM. | am extremely proud of the 
partnerships forged to provide insight, information and advice during the design 
and development of this document. My many thanks to the subject matter expert 
teams that aided in the modeling and evaluation of our business processes. — I look 
forward to the sustained support from my business partners in the on-going 
evolution of the Enterprise Architecture towards continually meeting BLM’s 
present and future business needs. 
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I. Executive Summary 


BEA—ACTIVE AGENT FOR SUPPORTING CHANGING BUSINESS NEEDS 


For the BLM Enterprise Architecture (BEA) to be successful, it must support the goals, strategies 
and business needs of the Bureau of Land Management (BLM). An understanding of the 
challenges and business priorities of the BLM over the next several years is essential for proper 
alignment of the BEA’s overall direction and ensuing actions. We must also understand the 
priorities of an organization may change overnight. The September |] terrorist attacks on our 
country made this very evident. Yesterday's business priorities may not be today’s, and both the 
BLM and its BEA must adjust accordingly. 


The BEA provides the road map for guiding the BLM’s information technology (IT) investments 
in order to meet its business needs. It also provides a tool for supporting business process 
improvement and redesign. A close alignment and interface with process owners, BLM 
managers, and executives and their needs is crucial to understanding all aspects of the challenges 
the BLM is facing. This is the first step in leveraging technology to meet these challenges. 


BEA—MAKING THE BLM’S OUTREACH MESSAGE A REALITY 


The BLM Outreach Message, which is based on the fiscal year (FY) 2002 budget. identifies four 
specific focus areas: 


¢ Energy, Minerals, and Rights-of-Way—We recommend the BLM strengthen its energy and 
minerals programs in order to combat America s energy shortage and promote the 
dependable. affordable, and environmentally sound production of energy. The processing of 
right-of-way (ROW) applications, which currently suffer from backlogs, is a dependent 
process in delivering local energy. 

¢ Urban Interface and Community Support—Western towns and cities near once-rem ote 
BLM lands are expanding and growing and the use of BLM lands for recreation is increasing. 
As a result, the BLM must significantly strengthen and update its land use plans (LUPs). This 
is the backbone of the process needed to make sound resource decisions. Updated planning is 
also needed to enable energy development and ROWs. 


¢ Critical Resources Protection—The BLM can effectively manage and protect critical 
resources by carefully identifying land management priorities. This will aid in maintaining 
the health of the land for a variety of public values such as watershed protection, exotic weed 
control, and abandoned mine restoration. 

¢ Special Areas—Specific western public lands that include spectacular landscapes have been 
designated for special management by the Congress and the President. The BLM welcomes 
the public interest and looks forward to working with State, local, and tribal governments: 
local businesses and conservation groups; and the general public in developing land use plans 
for each of these newly designated areas. 


An analysis of these focus areas suggests several key messages the BEA staff must integrate into 
its architecture priorities and direction. In the coming year, the BEA staff will emphasize 
planning- and energy-related business processes in its efforts to support the achievement of the 
above priorities. Several findings and recommendations included tn this report identify areas for 
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potential process improvement, improved data access and use, and proposed application 
components. All of these are critical mechanisms in ensuring the success of the BLM’s goals. 
The BEA staff looks to the Outreach document and other sources, including the Department of 
the Interior (DOT) and BLM strategic and annual performance plans, to help it gauge the business 
drivers the architecture must successfully accommodate. 


BEA—FY-2002 FOCUS AREAS 


This report contains several general and specific findings and recommendations based on 
analysis of the information flow modeling sessions and accompanying subject matter expert 
notes, analysis of data requirements and existing data redundancies, and a review of how well 
our current national applications support existing business needs. Based on these analyses, we 
recommend the BEA staff concentrate on several specific focus areas in FYO02. These areas are 
described in Table I-1 below. 





Architecture 
Layer FY01 Findings FY02 Focus 
| Process | Analysis of models indicates areas for @ Partner with process owners to provide 
| | process improvement in: reengineering expertise to improve business 
| @ Perform Planning Processes. 
| ¢ LUP @ Recommended focus of reengineering efforts 


should follow Pareto’s 80/20 rule. Focus 
resources In areas Where most improvements 
can be made. 


—@ = Authorize Use (Manage Land Use 
Activities) | 
@ Application for Permit to Drill 











(APD) | @  Reengineered processes will be captured as 
| | ¢ ROW | “Target Process Model” in BEA repository. 
Data @ Data redundaacy. sharing. and @~ Partner with business process owner, Data 
quality areas have been identified in | Stewards, and Data Administrators, 1n 
existing applications through the | accordance with the WO-200-sponsored data 
Corporate Metadata Repository | management plan, to plan, prioritize. and 
(CMR). | implement standardization. For example, this 


@ Thee BLM hes coined knowledac of effort will provide support to the IT tor a LUP 

| ey date te ened ten... create. wad business case, which, if approved. will be a 
&-: c . c . : — 7” . - : 

update. delete) at the data class level | significant BLM investment. 


for the BLM’s business processes. | @ Capture other data modeling and 
This knowledge can be used to standardization efforts underway and integrate 
further the data standardization into the BLM’s Target Data Architecture. 

| | process and improve data quality. @ Develop a web-based searchable database to 


publish the BLM’s national data standards 
through the corporate metadata repository. 














i) 
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Architecture 
ENTS FY01 Findings FY02 Focus 
Applications @ Analysis of models and existing | @ Seek sponsorship and assist sponsor in 
| applications indicates areas for | developing business cases for the following 
| crosscutting application components | crosscutting applications and enterprise data 
| and data stores. | stores: 


| @ Project managers need assistance in @ Customer nan ec and address 
reengineering business processes, 
particularly for major IT application | @ Continue data gathering and analysis of 
system development efforts. | applications architecture (e.g., planned 

| retirement/upgrade/replacement of existing 
apps.) to provide migration strategies from 
existing “As-Is” to Target Applications 
Architecture. Provides a plan for transitioning 
the BLM’s application portfolio to a defined 
target. This is an iterative effort that will grow 
over time. 


¢ Corporate document management system 

















pace 


a 








| Technology | @ = Future intrastructure requirements =| @ Leverage existing Enterprise Architecture 

| | including network bandwidth are | Infrastructure project in concert with the 

| dependent upon emerging business | National Operations Center to undertake a 

| needs. | BLM-wide infrastructure requirements 

t | analy SIS. 

_ Consolidation ¢ A conceptual Target Architecture ¢ Continue to evolve the Business-Driven Target 
| | approach has been developed that | Architecture that integrates the PDAT layers 

| | promotes reusability in data and | into a comprehensive approach with migration 
| | program logic. | Strategies that move the BLM from its 

| | | stovepiped “As-Is” architecture. This is an 

| iterative approach that will grow with time. | 








Table I-1. FY01 Findings and Recommended Focus Areas for FY02. 








As indicated above, our analysis of the BLM’s existing business processes, associated data 
requirements, and current automated applications points to several opportunities where the BEA 
staff can make positive, tangible business improvements. For example, we recommend the staff 
partner with the Project Manager for LUP. The goal would be to establish standard implemen- 
tation and tracking processes and mechanisms for approved land use plans at the national level. 
Some of the recommendations in this report are already being pursued through recently approved 
business cases such as providing information technology support for LUP. The BEA staff will 
partner with the business proponents to provide support in business process transformation and 
data standardization. The staff will also guide efforts to develop applications that can be 
integrated into the BLM’s target architecture. 


In this report, we present a conceptual target architecture that will promote the reusability of 
program logic and data. We also offer the initial components of this target architecture for 
implementation. This target architecture will provide an evolutionary, rather than a 
revolutionary, approach to migrating the BLM’s enterprise architecture (EA) toward its defined 
vision while emphasizing integration with the BLM’s existing legacy systems. 
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Summary Report 


BEA—2001 OVERVIEW OF SUMMARY REPORT 


Finally, as you read this Summary Report of Version 2 of the BEA, you will find discussions of 
the following topics: 


+ 


o 


+ 


A summary of the history of the BEA project. with a description of the modeling 
methodology used. 

A description of the emergence of and transition to a target BEA, moving from a picture of 
today to a vision of the future. 


A detailed presentation of our recommendation for a Component-Based Applications 
Architecture—founded on the principles of software reuse and a common data repository. 


General and specific Findings and Recommendations, including 20 actions for review. 
Planning and scheduling considerations. 


A discussion of Architecture Governance, a guide to making “good” IT investments. 


Ot all of the accomplishments of the BEA Core Team thus far, the most significant is the 
understanding of the need to adopt a component-based applications architecture where 
reusability of data and program logic can be put to good use. This understanding underpins 
most of the other Findings and Recommendations contained in this report. 


As with all documents of this nature, the scope of the recommendations may seen daunting at 
first. However, improving the BLM’s business processes is imperative to the health of the 
enterprise. Improvements will be implemented one step at a time, with reusability, reengineering, 
and teamwork foremost. 
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II. Introduction 


The discussion that follows in this Summary Report addresses the BLM Enterprise Architecture 
(EEA) ina holistic manner. It identifies drivers within the Federal Government for enterprise 
architectures (EA), defines the term as it is used within the Federal Government, and 
differentiates between current and target BLM architectures. It also describes the critical 
relationships among EA, agency-level strategic planning, and capital investment planning. The 
discussion highlights the accomplishments of the BLM Core Team to date, and addresses how 
those accomplishments might lead to future efforts. Recommended future efforts are proposed 
based on specific findings resulting from past efforts. 


Two themes are emphasized throughout this report: (1) institutionalizing the integration of the 
BEA with IT investment management, including capital planning investment procedures, and 
(2) evolving a component-based applications architecture where reusability can be used to 
support future BLM business requirements. In support of the evolution toward a component- 
based applications architecture, we recommend the BEA staff concentrate its recommended 
efforts over the next year in the following areas: 


Creation and implementation of data standards in specific functional areas. 

Business process transformation in specific functional areas that meet high-priority program 
needs, such as Land Use Planning (1 '!P), Application for Permit to Drill (APD), Expression 
of Interest (EOI), and Right of Way (ROW). 


Evolution and definition of a Target Architecture. 


Development of a sequencing plan to migrate from the current BLM architecture to the target 
architecture. 
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Ill. Background 


A, PURPOSE 


The purpose of this Summary Report is to communicate major findings from the analysis 
performed on information collected to date and. more important, to present recommendations for 
enhancing the current environment while simultaneously moving toward an improved target 
environment. 


B. THE BLM ENTERPRISE ARCHITECTURE 


The BLM’s business is to manage public land and resources. To manage the land and resources 
effectively, the BLM needs to manage information about both those resources and its customers. 
Understanding and improving the BLM’s business processes, data, and supporting applications 
are crucial in managing that information. The BEA effort is the primary vehicle used by the 
BLM to analyze and document its processes, data, applications, and technology infrastructure. 
The analysis, in turn, leads to recommendations that translate into improved business-driven 
land- and resource-management decisions. 


The method used to organize and analyze the BEA focuses on four discrete but interrelated 
enterprise areas: business processes, data, applications, and technology (the enterprise's 
infrastructure). Whereas architecture should always be viewed as whole, and not just broken 
down into discrete areas, the analysis also addresses a “consolidation” area that draws together 
each oj the four areas. In abbreviated form, the four areas are referred to as “PDAT.” which 
represents: 


@ Process. 
¢ Data. 
¢ Applications, and 


¢ Technology. 


7 


The four areas are related as indicated in Figure III.B-1. 




















Dx ah ee 
“termine 
Determun Requirements tor > Data 
Requirements tor Architecture 
. 
» Business | 
Processes Determines 
a Requirements tor 
Determine 
Determun Requirements tor 
. Requirements toy 
Technology 4 Applications 
Architecture Architecture 
. 2 Determines requirements tor ——EEE . 


Figure III.B-1. PDAT Relationships 
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In short, the BEA is a representation of all the BLM is and does. With both what the BLM is and, 
in particular, how it performs its work change over time, the BEA ts an evolving representation 
of the BLM—as the BLM changes, the BEA must also change. One of the most important 
reasons for developing and maintaining an EA is to support change management within the 
enterprise. As knowledge about the enterprise increases and is captured in the EA, change 
management becomes a more manageable task. EA efforts necessarily begin with a high-level 
understanding of the enterprise's processes, data, applications, and technology. Ultimately, the 
goal is to understand each of these areas in detail. Any information that is not fully known and 
understood requires an assumption—increasing the level of uncertainty during the decision- 
making process. Although the architecture typically focuses on technological change, it also 
supports business process improvement and change independently of technology. 


The BLM initiated action in | \99 to develop its BEA to align its information technology more 
effectively with the needs 0! the BEM business programs. Version 1.0 of the BEA, published in 
March 2001, focused on depicting the BLM’s current environment. This Summary Report of 
BEA Version 2.0 is a continuation of that initial effort and builds on the findings and 
recommendations included in the Version 1.0 report with more detailed findings and 
recommendations. It adds to the understanding of the current environment and presents a 
conceptual target environment. A key focus of the BEA effort over the next year will be to use 
the target environment concept to design critical elements of the target environment. 


Development of the target environment will set the stage for a gap analysis to determine more 
precisely what needs to be done to move from the current environment to the desired target 
environment. The gap analysis also provides the basis for developing a multi-year transition. The 
transition plan, in turn, provides input to the BLM’s IRM planning efforts and serves as the basis 
for capital investment planning. 


C. ALIGNMENT WITH THE DOI ARCHITECTURE VISION 


The Department of the Interior (DOI) recently published a Common Requirements Vision (CRV) 
that will provide the basis for the development of the DOI Enterprise Architecture. This vision 
document is used to ensure the DOI's IT products and services are aligned with the business 
community's strategic direction. It was derived from executive and management interviews, 
reviews, and analyses of strategic plans at the DOI and Bureau levels. This document identifies 
the following focus areas in technology, based on environmental trends and DOI business 
strategies: 


1. Improve data management systems (e.g., policy and procedures relating to data standards, 
data privacy, data security, etc.). 


tl 


Encourage innovation in our products and services by keeping abreast of and applying new 
technologies and work practices. 
3. Use new collections management software to improve the efficiency of inventory data entry 
and management. 
4. Develop reusable, consistent, and sharable components (e.g., standards, guidelines, 
procedures, etc.) for the Information (Interior-wide) Architecture Service Areas. 
5. Complete implementation of an off-the-shelf software product with improved functionality 
and ad-hoc reporting capabilities to enable the DOI to consolidate tracking of material 
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weaknesses (both program and financial management) and OIG, GAO and Single Audit 
recommendations and provide for direct Bureau updates on the status of corrective action and 
implementation activities. 
6. Respond to the increasing need for faster, more complete access to information by Interior 
personnel to improve service delivery, worker productivity, and management of public 
resources, 
7. Address the increasing demand for the capture, electronic storage, delivery, and archiving of 
Interior resources (including those currently paper-based). 
8. Close the growing gap between the cycles of technology evolution and the planning, 
budgeting and procurement cycle within government (e.g., acquisitions are often obsolete 
before deployment). 
9. Align the BLM’s architecture direction with the Department's IT focus areas. For example: 
a Data is akey BLM focus area, as demonstrated in six recommended actions to be taken 
to improve the quality, access, and storage of data. 

4 Reusable components are used where appropriate in BEA’s target, component-based 
architecture, 
Standardization is a recurring theme throughout this document. 


The BEA approach is one of evolution. Architectural integrity, completeness, and 
currency must be maintained or these efforts will not achieve their intended results. 


The BEA staff fully supports each of these areas and will continue to implement them in a 
proactive manner. 


D. VALUE OF ENTERPRISE ARCHITECTURE (EA) TO THE BLM 


The Clinger-Cohen Act of 1996 requires each federal agency to have an EA. The value of an EA 
to the BLM goes far beyond meeting statutory requirements. In its higher-level versions, the 
BEA provides the BLM’s management with information for making and justifying critical 
business decisions, e.g., where business processes should be transformed to gain greater 
efficiencies, how to make information more accessible to both the public and managers, or how 
best to invest IT resources to achieve the highest possible return on investment. 


In addition, in its more detailed versions, the BEA will provide essential information enabling 
the BLM to do the following: 


Transform business processes into more efficient work efforts. 

Standardize data within the BLM. 

Design more efficient use of applications for automating work processes and sharing data 
between those processes. 


¢ Design, develop, or procure specific technological solutions. 
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Figure III.D-1 depicts how the BEA effort is integrated with and supports strategic planning, 
capital investment management, and acquisition capability within the BLM. 
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Figure II1.D-1. Integration of the BEA with Strategic and Capital Investment Planning. _ 





Figure III.D-1 indicates the BLM’s strategic plan and resulting business requirements should 
drive the BEA. This is already happening within the BLM, as shown by the concentration of 
recommendations (see Section V) dealing with applications for permit to drill (APD), rights-of- 
way (ROW), and land use planning (LUP). The BLM’s 2002 Budget Justifications repeatedly 
mention the growing importance of those three processes in meeting emerging demands for 
BLM land use. 


The recommendations included in Section V of this report respond directly to the focus areas 
cited in the 2002 Budget Justifications. These areas identify critical business requirements within 
the BLM. The analysis of the “As-Is” BEA identified similar critical business requirements. We 
have responded to them with practical evolutionary steps that will enhance the BLM’s ability to 
improve both the efficiency of its relevant business processes and the quality and accessibility of 
the information necessary to meet customer needs and support sound decision-making. 


FE. BLM INITIATIVES 


Over the past year, the BLM has initiated action in three broad areas. The BLM will: (1) 
continue development and analysis of the current BEA in terms of business processes, data, and 
applications; (2) integrate the BEA with the strategic and capital investment planning and budget 
priorities; and (3) develop a concept of a target BEA environment toward which the BLM can 
migrate. These three initiatives have led to numerous specific accomplishments summarized in 
Table III.E-1. 
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Initiative 


Summary Report 


Accomplishments 





1. Continue development and 
analysis of the current BEA. 


Expanded knowledge of the BLM’s business processes through subject 
matter expert (SME) sessions. 

Identified areas where current process models suggest opportunities for 
process improvement. 

Developed a streamlined target process model that consolidates nine 
Activity-based Costing (ABC) process areas into six. 

Mapped high-level data classes to business processes. 

Identified data quality issues through the corporate metadata repository 
(CMR) to use as a basis for improving the BLM’s data. 

Inventoried 26 national applications and mapped them to processes and 
data. 





2. Integrate the BEA with 
strategic planning and capital 
investment planning. 


Established architecture alignment criteria for evaluating business 
cases. 

Evaluated business cases for architectural conformance and made 
recommendations to the Information Technology Investment Board 
(ITIB). 





3. Develop a concept fora 
target BEA environment. 








Defined concept for a component-based applications architecture to 
guide future applications development efforts. 





Table III.E-1. Initiatives and Accomplishments. 





Of all the accomplishments thus far, the most significant is the understanding of the need to 
adopt a component-based applications architecture that provides for the reusability of both data 
and program logic. It became clear, during analysis of the current BEA, that the present situation 
regarding both data and existing applications needs to be changed if the BLM is to improve its 
ability to make information available to its customers and managers. Applications in the current 
environment have limited sharing of appropriate data, resulting in redundant data of reduced 
quality. The component-based applications architecture, which will continue to reflect PDAT, 
will provide a means to correct this situation as well as the opportunity to further enhance the 
automation available to the BLM’s business processes. Figure III.E-1 compares the 
characteristics of the current and target environments. 
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Figure III.E-1. Characteristics of Current vs. Target Environments. 
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F. BLM ACCOMPLISHMENTS 


Defining the Baseline Architecture 





In FY 2001, the BLM made substantial progress in defining its 

baseline, or current, architecture. This is the first step in “In building the EA, 
developing an enterprise architecture (EA). The current a logical first step is 
architecture allows future progress to be measured against an describing the current 
established baseline. The old saying “You don’t know where or "'As-Is" state.” 
you're going if you don’t know where you've been” is also true —A Practical Guide 
for architecture development. The first step is to establish a set of | to Federal Enterprise 
architectural products that describe and document the current Architecture (2/2001) 
state of the enterprise, from business functions to technology 











infrastructure. This sets the stage for establishing a plan for 
moving toward, and measuring progress against, a ““To-Be” architecture. 


Process Layer 





For an architecture development effort to be successful, it 

must be driven by the needs of business, not those of In order to improve our 
technology. Architectures driven by technology are akin to a business processes, we 
solution looking for a problem. We must first understand the must first identify them. 











BLM’s business processes. This understanding, in turn, 
enables us to define data, applications, and technology requirements. 


The first step in building a business-driven architecture is identifying the current business 
processes. Dr. Michael Hammer, a well-known expert in business process reengineering, stated: 
“Only processes can be reengineered. Before you can reengineer your processes, you must 
identify them.” This statement holds true for any process improvement effort. To improve our 
business processes, we must first identify them. 


BLM expanded the definition of its current business processes in FYO1 through the use of 
facilitated subject matter expert (SME) teams. These teams included representatives from 
program offices at the field, State, and headquarters levels. Each SME team furthered the 
documentation of the BLM’s business processes by identifying “What We Do” in relation to a 
specified business subject area. These process models pinpointed potential areas for business 
process improvements and reengineering efforts. We analyzed them to define the following 
needs: 


¢ Opportunities to streamline and improve the BLM’s business processes 
4 Duplication of processes that “touch” same/similar data 
a Overly complex processes 

# Areas where business processes are not well established, resulting in: 
4 Inconsistent business practices 


4 Inconsistent results 
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The BLM has used the Activity-based Costing (ABC) model, which originally included nine 
business subject areas, to further define and analyze its business processes. Based on the input of 
the SMEs and the analysis of the ABC-derived process model, the BEA Team has realigned the 
business processes into a model with six business subject areas for the target business process 
architecture. The target process model eliminates duplication and will better support business 
process redesign. Process owners may use these models as a baseline for future process 
improvement and reengineering efforts. 


Each level of decomposition, or breakdown, in a process model provides the BLM with 
increasingly more detail about its business processes. Figure III.F-1 shows the level of 
decomposition modeled for each business subject area by the end of FYO1. 





Status of Modeling—Fiscal Year 01 


“As-ls” Information Flow Modeling of Nine Business Subject Areas 


. 
Level 5 
gS a | 








¢ Provide Customer ¢ Perform Assessment ¢ Authorize Use 
Service ¢ Implement BLM Initiated ° Perform Planning 
¢ Perform Monitoring Action ¢ Implement BLM Initiated 
¢ Manage Compliance * Hazmat Action 
e Sustain Organization ¢ Abandoned Mining ¢ Facilities 
¢ Adm & Financiali— Lands ¢ Sustain the Organization 
Level 2 ¢ Provide HR 
e |RM—Level 2 Management Support 
¢ Executive Direction 
and Comm.—Level 2 

















Figure III.F-1. Decomposition Levels by Business Subject Area. 





Data Layer 


Data is the “Rosetta Stone” of architecture. This includes ownership, integration, integrity, 
quality, reuse, security, privacy, and use of the data. All of these areas must be addressed, both 
within each process and across processes. Access to information, from the backbone network to 
the privileges afforded BLM personnel and the general public, must be provided for within the 
framework of the architecture. 





Business processes drive data requirements. Data is a key layer 
in defining the BEA. The BLM leveraged information from We have a better 

prior data modeling efforts (e.g., its 1989 enterprise data understanding of what 
model) to expedite the definition of its enterprise data data is used by our 
architecture. As this new model is further refined, it will business processes, which 
become a critical component in guiding future application will aid in minimizing data 
development efforts intended to minimize existing data n edundancy and improving 
redundancies and guide corporate data standardization efforts. data quality. 

Architecture outputs at the data layer include: 














Enterprise-wide Data Requirements 

Existing Data Redundancies within National Applications 
Existing Data Quality Issues 

Areas for Standardization Recommendations 


“+ ¢ + 
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Mapping Data to Business Processes 


This year, the BLM mapped approximately 90 data classes to 260 business processes. This 

helped the BLM to improve its understanding of how data is used in the organization and to 
determine the data used by each business process. That data can be divided into classes and 
elements. 


A data class is a high-level grouping of data. For example, Case Information is a data class, 
while application information, case action information, and case status information are examples 
of data entities within that data class. Through this better understanding of the data used by its 
business processes, the BLM will be able to minimize data redundancy. 


In mapping data to processes, the BLM examined whether data was Created, Read, Updated, 
and/or Deleted (CRUD) by business processes. Multiple business processes that create the same 
data result in data redundancy, which leads to additional data storage needs and potential data 
quality issues. Optimally, the BLM wants to create data once and reuse it where necessary 
throughout the BLM. From the CRUD matrix, the BLM has gained a better understanding of its 
data requirements as well as areas where data redundancy may exist. This matrix, an example of 
which is shown in Figure III.F-2, will be examined further and refined as necessary in FY02 to 
guide the continual definition of the BLM’s target data architecture. Ongoing review and input of 
this matrix by its National and State Data Administrators, Data Stewards, and Bureau Data 
Administrator is essential. The CRUD matrix helped to identify some of the problems with the 
‘As Is” business process model. The target business process model will minimize the problem of 
multiple processes creating the same data. This, in turn, will support improved business 
processes and better data management. 


Data Classes 


Business Process Case Action 














Evaluate Environmental Hazard (EH) C U 


Figure III.F-2. Example Extract from CRUD Matrix. 








Investigating Data within Existing National Applications 


As the BLM defines its target architecture, information about the current state of its automated 


data becomes crucial. The Corporate Metadata Repository (CMR) is the 


BLM'’s prime source of metadata for non-spatial national 
applications and the reference point for BLM-wide data standards. 
Corporate Metadata Repository 






Combining this information with the CRUD matrix cited above 
provides the BLM with the information needed to convert the 
current systems to an architecture enabling access to shareable 
enterprise data. While progress is being made to adopt spatial data 
standards, spatial data is not currently being stored in the CMR. Thus, the efficient integration of 
spatial and textural data is still absent. 


Thirty-two national applications, including those listed in Table III.-F-1, have been loaded into 
the CMR by the Data Management Team in the System Coordination Office (SCO). The team 
examined this database to provide information associated with data quality and redundancy 
issues. The Data Management Team works closely with the BEA staff in defining the BLM’s 
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target data architecture. The implementation of the BLM’s target data architecture will adhere to 
the products of the Data Management Plan currently being implemented under the sponsorship 
of WO-200. This plan outlines the roles, responsibilities, and processes for managing data and 
establishing enterprise-wide data standards within the BLM. 





System Name Acronym Database Loaded 




















Alaska Land Information System ALIS Yes 
Automated Fleet Management System AM Yes 
Automated Fluid Minerals Support System AFMSS Yes 
Bond and Surety System BSS Yes 
Cadastral Survey Field Notes Index System CSFN Yes 
Collection and Billing System CBS Yes 

















Table III.F-1. Sample of Information Available in the Corporate Metadata Repository. 





Applications Layer 


Beyond examining applications from a data standpoint, 26 national applications also were 
analyzed to determine the “As-Is” business processes supported. Although they represent only a 
subset of the total national applications, we have used this analysis as a starting point in 
determining gaps and overlaps in the BLM’s current applications architecture. During FYO1, 123 
business processes and 32 data subject areas were mapped to the applications evaluated. Gaining 
a better understanding of the national applications will lead to solid transition strategies as the 
target architecture is defined. National applications nearing the end of their life cycle will be 
reviewed for transition to the target architecture. 


Table III.F-2 presents sample findings from the survey of national applications conducted in 
FYOI. 





Application Finding 
Alaska Land ¢ Supports 19 processes across seven ABC areas 
Information ¢ Privately stores data from 17 data subject areas (DSAs) and shares data from | 
System (ALIS) DSA 





Automated Fluid ¢ Supports 25 processes across five ABC areas 
Minerals Support 


¢ Privately stores data from 15 DSAs 
System (AFMSS) 





Collection and ¢ Supports 24 processes across six ABC areas 
Billing System Deady and eciten dun 6 11 DSAs. Data f ight DSAs are duplicated 
(CBS) @ Reads and writes data from SAs. Data from eight DSAs are duplicate 


from or to another application. Data from the other three DSAs are in private 
data stores. 














Table III.F-2. National Application Survey Findings. 





Obsolescence reviews will be conducted in FY02 to focus on defining the target applications 
architecture. 
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Technology Layer 


The Technology Layer consists of the BLM’s IT infrastructure—its hardware, communications 
systems, and operating systems. The infrastructure is literally the backbone of the enterprise. It is 
the structure enabling the applications to provide and manage information required by the 
business processes. 


The Technical Reference Model (TRM) is a cross-cutting element, affecting all components of 
the BLM Enterprise Architecture (BEA). It identifies and describes the information services used 
throughout the BLM and the standards profiles that have become the cornerstone of 
interoperability within the BLM. During the past year, Volumes I and II of the TRM have been 
published. The TRM will be updated regularly to reflect business-driven requirements and 
improvements in technology. 
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IV. Emergence to a Target BEA 


A, MIGRATION FROM CURRENT TO TARGET EA 


Analysis of the accomplishments of the past year provides a focus for activities in FYQ2 that will 
initiate the BLM’s migration toward a target environment. The BLM now has a solid, high-level 
understanding of its current enterprise architecture. Analysis of that architecture has revealed 
potential areas for enhancement. Table [V.A-1 describes those findings and the focus they 
provide for FY02. 








Architecture 
Layer FY01 Findings FY02 Focus 
Process Analysis of models indicate there are ¢ Partner with process owners to provide 
areas for process improvement in: reengineering expertise to iiprove business 
@ Perform Planning Processes. 
¢ LUP @ Recommended focus of reengineering efforts 
¢ Authorize Use (Manage Land Use should follow Pareto’s 80/20 rule. Focus 
Activities) resources in areas where most improvements 
® APD can be made. 
@ ROW @ Reengineered processes will be captured as 
“Target Process Model” in BEA repository. 
Data @ Data redundancy, sharing, and @ Partner with business process owner, Data 
quality areas have been identified in Stewards, and Data Administrators, in 
existing applications through the accordance with the WO-200-sponsored Data 
Corporate Metadata Repository Management Plan, to plan, prioritize, and 
(CMR). implement standardization. For example, this 
@ The BLM has gained a knowledge effort will provide support to the IT for an LUP 
of how data is used (e.g., Create, business case, which, if approved, will be a 
Read, Update. Delete) at the data significant BLM investment. 
class level for its business @ Capture other data modeling and 
processes. It can use this knowledge standardization efforts underway and integrate 
to further the data standardization them into the BLM’s Target Data Architecture. 
process and improve data quality. @ Develop a web-based searchable database to 


publish the BLM’s national data standards 
through the corporate metadata repository. 








Applications @ Analysis of models and existing @ Seek sponsorship and assist sponsor in 
applications indicates areas for developing business cases for the following 
crosscutting application components crosscutting applications and enterprise data 
and data stores. stores: 

@ = Project managers need assistance in @ Customer name and address 
reengineering business processes, @ Corporate document management system 
particularly for major IT application | @ Continue data gathering and analysis of 
system development efforts. applications architecture (e.g., planned 


retirement/upgrade/replacement of existing 
apps.) to provide migration strategies from 
existing “As-Is” to Target Applications 
Architecture. Provides a plan for transitioning 
the BLM’s application portfolio to a defined 
target. This is an iterative effort that will grow 
over time. 
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Architecture 
Layer FY01 Findings FY02 Focus 

Technology ¢ Future infrastructure requirements @ Leverage existing Enterprise Architecture 
including network bandwidth are Infrastructure project in concert with the 
dependent upon emerging business National Operations Center to undertake a 
needs. BLM-wide infrastructure requirements 

analysis. 

Consolidation ¢ <Aconceptual Target Architecture @ Continue to evolve the Business-Driven Target 
approach has been developed that Architecture that integrates the PDAT layers 
promotes reusability in data and into a comprehensive approach with migration 
program logic. strategies that move the BLM from its 

stovepiped “As-Is” architecture. This is an 
iterative approach that will grow with time. 








Table IV.A-1. Summary of FY01 Findings and Focus for FY02. 





The BLM’s target Enterprise Architecture (EA) will describe the environment toward which the 
BLM will migrate. Within each of the areas of the PDAT, some elements of the current 
architecture will migrate to the target environment, some will sunset, and other completely new 
elements will emerge. Figure I1V.A-1 depicts this concept as endorsed by the Federal CIO 
Council in the Federal Enterprise Architecture Framework. 
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Figure IV.A-1. The Federal Enterprise Architecture Framework. 




















B. HIGH-LEVEL AN 4i.. S'S OF THE CURRENT BEA 


The current BEA is the product of the analysis and modeling of the BLM’s current environment. 
It is structured in the ‘our | DAT layers—business processes, data, applications, and technology. 
An analysis of each of tnese layers follows. 
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Business Processes 


Business processes are identified and modeled to reflect the enterprise's activities, the 
relationships between processes and business drivers, the relationships among the processes 
themselves, and the information that flows between processes. The modeling to date has been 
based on the BLM’s Activity-based Costing (ABC) model. This model was originally developed 
to employ active cost management in the BLM. 


The ABC model consists of nine high-level processes that were broken down to various levels of 
detail, some of which are at the sixth and seventh levels, and further broken down into more than 
1,200 processes. A review of those processes revealed an excessive number of redundant 
processes. For example, the first level of the “Use Authorization” process was broken down into 
167 subordinate processes. Of those 167, there are 20 different sets of processes with the same 
name. This accounted for 66 of the 167 processes found in the model. In addition, five of the 
program elements within Use Authorization have the same set of subprocesses. Across the 
enterprise, 37 percent of all processes appeared to be duplicated in separate program elements. 
(See Initial Bureau Architecture (Version 1.0), Summary Report, page 46, for more detail.) 


Participants in the SME sessions highlighted numerous examples of duplication and 
recommendations for change. Examples of their recommendations include the following: 


Merging Authorize Use with Implement BLM-initiated Action 
Combining all information collection processes 


Combining all planning processes 


- ¢ ¢ 


Combining all analytical processes 


Redundant processes are a symptom of the stove-piping of business activities among program 
elements. As typical of many organizations, this redundancy is the natural result of the historical 
development of the BLM. The problem has been exacerbated by new mandates and targeted 
funding allocations. 


During the past two months, a new business process model has been developed presenting a 
more concise structure for analyzing the BLM’s processes from an information management 
perspective. The new model is discussed further in the Findings and Recommendations section 
of this report. We expect this proposed new model will accelerate the analysis of the BLM’s 
information requirements. 


Data 


We took two approaches (bottom-up and top-down) simultaneously to gain an understanding of 
the BLM’s current data environment. In the bottom-up approach, 17 national applications 
identified in the CMR were reverse-engineered to identify the data used by those applications. 
More than 5,000 data entities were identified. One hundred and thirteen (113) data structures 
were identified as having properties that are independent of any unique application. As they are 
common to many BLM applications, they are candidates for component development. 
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In the process, we identified numerous Business Area Components. They may be grouped into 
the following major headings: 


+ Account ¢ Organization 
BLM Administrative Area + Party 

+ Case + Project 

+ Customer # State Relations 

¢ Contract @ Use Authorization 
¢ Document Management ¢ Withdrawal 

+ Geographic Location 


These Business Area Components are much too large to be architected into single components 
and would, therefore, be partitioned into several components as physical performance 
engineering requirements dictate. 


The top-down approach to data modeling resulted in the development of an enterprise-wide 
logical data model with 13 data subject areas and more than 200 data entities. Previous data 
modeling efforts—for example, the 1989 Enterprise Data Model, 1991 Enterprise Data Model, 
and AL? {RS data model—were reviewed. They served as a basis for development of the new 
logical data model, which now, in turn, serves as the basis upon which to build data models for 
specific functional areas. 


Applications 


We inventoried 26 of the 44 national applications listed in the Corporate Metadata Repository 
(CMR). Analysis of the information collected indicated the following: 


@ Of the 26 applications, 22 use at least some private data stores. The data in these stores is not 
shared with other applications. In fact, 14 of the 22 applications do not share any of their 
data. 


Thirteen of the 26 write customer data. Of these, seven write to private data stores. 
Six of the 26 write employee data. Of these, five write to private data stores 


Only four of the 26 applications automate a Level 3 business process. Most simply provide 
access to data. 


Figure IV.B-1 portrays the current BLM applications architecture as gathered from system 
owners. Analysis of this graphic leads to several conclusions: 


¢ A considerable amount of information flows between BLM applications and other Federal 
Government agencies and external organizations. 


@ Very little information flows between BLM applications. 
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Technology 


Analysis of the technology layer was conducted in conjunction with the development of the 
Technical Reference Model Versions I and II. For further information on the analysis regarding 
this layer, please refer to those documents. 
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Figure IV.B-1. The BLM’s Current Applications Architecture. 





C. CONCEPT FOR COMPONENT-BASED APPLICATIONS ARCHITECTURE 


One of the two major themes of this report is the potential value to the BLM of migrating to a 
component-based architecture. A component-based architecture provides a flexible software 
system in which newly created component-based services and features, including Commercial- 
Off-The-Shelf (COTS) packages, can be seamlessly integrated and manipulated by the existing 
system. That concept and its potential value to the BLM are discussed in this section. 


A component is a reusable element of a larger system. It can be used by any application, running 
on any processor in the infrastructure, using data available from anywhere in the enterprise. In a 
component-based architecture, the applications contain pointers to components for reusable 
processes and data. Software is assembled rather than created. New applications are built from 
components that communicate with each other through well-defined interfaces. These 
components are individual pieces of software that provide specific functionality and may be 
executed together to achieve certain tasks. 
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In developing a component-based architecture, there are several objectives: 


1. Interoperability and plug and play. Heterogeneous databases should be interoperable and 
easily integrated into the architecture. 


'N 


Scalability and extensibility. Architecture components should be scalable, extensible, and 
easy to add to or remove from the architecture. 


3. Flexible. The amount of data to be treated may be very large and should be able to be 
balanced by distributing the work among several components and machines. 


4. Transparent. Users should be able to access different data sources in a transparent manner. 
Achieving these objectives will result in numerous benefits to the BLM. For example: 


¢ Cost savings. Because the components are reused and shared, their code has to be created 
only once instead of having to be recreated in multiple applications. This can dramatically 
reduce development costs. 


¢ Higher data quality. The data used by the components becomes an enterprise asset. This 
helps to eliminate data redundancy. 


Figure IV.C-1 depicts the concept of component-based applications architecture. 
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Figure IV.C-1. Concept for Component-Based Applications Architecture. 
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As shown in the figure, there are five types of elements in a component-based applications 
architecture. Starting at the bottom of the figure and working up, the elements include: 


1. Enterprise Information Data Store (ETDS). The concept is based on quality data used as an 
enterprise asset and stored in an EIDS. 


' 


Component. Any number of reusable and shareable components that draw on standardized 
data in the EIDS can be created. 


3. Applications. Any number of new or legacy applications that draw on the components can be 
created. 


4. Processes. Processes include the major business functions performed by the BLM. 


5. Technology. This element includes the hardware, operating systems, and communications 
systems that support application and data requirements. Because component-based 
applications are designed to be platform-independent, specific technology elements are not 
addressed in the figure. 


EIDS Element 


An EIDS can only be created after enterprise-level data standards have been established and 
implemented and quality data has been compiled. Quality data is the foundation upon which 
component-based applications architecture is built. As it takes time to add quality to data, we can 
expect implementation of the EIDS will occur piece by piece, with each piece representing a 
different data subject area. The BLM’s data subject areas, as currently modeled, are indicated in 
the EIDS element in Figure 1V.C-1. The concept of component architecture is so flexible that not 
all the data in a particular data subject area has to be populated in the EIDS at a single time. For 
example, if a decision is made to focus attention on developing a component for Rights of Way 
(ROW), initially the EIDS only needs to be populated with the data in the “Rights” data subject 
area germane to ROW. 


Before data from any data subject area can be entered into the EIDS, the data model needs to 
address the relationship between spatial features such as roads stored in the Spatial Database 
Engine (SDE) and the attributes of roads stored in the EIDS. In other words, spatial data needs to 
be integrated with textual data in the EIDS. The Data Management Plan provides the necessary 
guidance and procedures for defining roles, setting standards, and managing data as an asset. 
They will be followed during this process. The data should first be modeled and standardized to 
eliminate redundancy and ensure quality. The EIDS would then be populated and the data made 
available for either new components or existing applications. The EIDS would grow over time as 
data from different data subject areas was migrated to the EIDS in a priority order established by 
business requirements. 


The major advantages of adopting an EIDS are as follows: 


# Data redundancy will be minimized. 
# Greater accessibility to common types of information will be realized. 


¢ Standardization of data will begin to improve data quality. 
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¢ Data storage requirements will be reduced. 


¢ The BLM’s data will become available to the entire enterprise rather than solely to specific 
applications. (The BLM could limit access to specific data by implementing and controlling 
access rights.) 


Component Element 


The primary characteristics of components are they are reusable and shareable. Reusable means 
that an application can employ their functionality over and over again. Shareable means more 
than one application can use the same component. An example of a component is the spell-check 
capability in the Microsoft Office suite. A single instance of spell check is coded in the suite and 
used jointly by Microsoft Word, Excel, and PowerPoint. Thus, the expense of coding a spell- 
check capability and maintaining it in three different applications is avoided. Technically 
speaking, a component bundles together data and business rules. 


Figure IV.C-1 suggests the BLM’s first two components might be Legal Entity and Request 
Management. (Details concerning specific recommendations for these two components are 
included in Section V of this report.) The Legal Entity component would address business needs 
to standardize data and business rules for what is commonly called “Name and Address.” The 
Request Management component would do the same for requests submitted by customers to the 
BLM. Both components would support immediate business requirements to improve customer 
service. An essential ingredient of the concept for component-based applications architecture is 
that implementation can evolve at the speed the BLM chooses. Some components may be 
developed and implemented at later dates. COTS products also may be components. 


The major advantages of component -based applications are as follows: 


# Reduced cost of development and maintenance. An initial, high-level ROI study indicates the 
BLM could reduce development costs significantly over the next 10 years by employing 
components for commonly used data in the national applications in the CMR. 


¢ Reduced time to market. Industry studies indicate a significant reduction in time to market 
for development when components are used. 


¢ Components are more easily upgraded and replaced as requirements and technology 
opportunities dictate, without the level of impact normally associated with a more traditional, 
self-contained, stovepipe application environment. 


Applications Element 


The end products of a component-based applications architecture are the applications that 
support business requirements. Each application is a single object in the applications 
architecture. Both new custom applications, as they are developed, and compatible COTS 
products rely on reusable and shareable components to meet functional needs. COTS products 
would contain reusable and sharable components. Many organizations have found it beneficial to 
establish incentives for developers to employ existing components rather than to develop new 
application code. As more and more components are developed, new applications have more 
components to choose from, leading to greater flexibility for application development and 
greater standardization of automated processes within the BLM. 
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Figure IV.C-1 shows, for ex. nple, a customer management application might be developed 
initially using the capabilitic. »¥ the legal entity and request management components, as 
indicated by the solid connector lines. Subsequently, as new components are developed (shown 
by the dashed connector lines), new Use Authorization and Case Tracking applications might use 
these components as well as thers. 


For the BLM, the major advantages of component-based applications are as follows: 


¢ Adaptability. By using pre-existing components, each application can be easily and quickly 
designed and developed to meet specific business requirements. The application developer 
needs only to develop a pointer to these components to take advantage of them. 


¢ Reduced cost of maintenance. The life cycle of an application is greatly lengthened. A 
component may become obsolete due to changes in data or functionality, but the application, 
because ii is composed of discrete bui!ding blocks, does not lose all its functionality. The 
obsolete component can be replaced more quickly and inexpensively than the entire 
application. 

¢ Evolution. The transition to a component-based applications architecture can be evolutionary 
rather than revolutionary. The use of components need not immediately make all legacy 
applications obsolete. Legacy applications can continue to function as they always have. 
When components are developed that could replace some functionality of a legacy 
application, the BLM can decide whether it is economically justifiable to reengineer the 
legacy application to point to the new component in order to take advantage of that new 
capability. Figure 1V.C-2 shows how the migration process can be facilitated using 
middleware products. 


¢ Standardization of enterprise data. The development and use of components will hasten the 
standardization of data within the BLM. Before a new component is implemented, its data 
will be standardized and migrated to the EIDS. Each application that uses the component, 
whether new or legacy, will be able to take advantage of the newly standardized data. The 
potential to use quality, standardized data should entice owners of legacy applications to 
reengineer those applications to take advantage of that data. This will foster the rapid 
adoption of the component-based application concept. Figure I1V.C-2 indicates how a COTS 
middleware product might be used during the transition to standar 1ze data more rapidly and 
make the data available to both legacy and new applications. 
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Migration to Component-Based Applications 
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Figure IV.C-2. Migration Using Middleware. 





Processes Element 


An Enterprise Architecture (EA) should be driven by business, not technological, needs. 
Technological solutions are used to support specific business requirements. In order to 
understand business needs, we first need to understand what it is the business does. We gain 
that understanding by identifying business processes. 


Processes are the activities performed by the enterprise to accomplish its mission. They represent 
the business of the enterprise. We develop business process models to define the enterprise’s 
business requirements and clarify exactly what the enterprise does. The more detailed the model, 
the clearer our picture of the business becomes. 


Figure IV.C-1 shows the six highest-level processes in the evolving target process model. These 
SIX processes represent everything the BLM does. We add detail by breaking down the high-level 
processes into child or subordinate processes. The greater the level of decomposition, the more 
the user of the model can know about the detailed activities performed by the enterprise. Once 
we understand the business processes, we can identify and determine the data required to support 
these processes, the applications required to manage the data and automate the processes, and the 
hardware needed to support the applications. Thus, the entire EA becomes driven by business 
requirements. 
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The major advantages of business process modeling are as follows: 


¢ It identifies business requirements. 
¢ It leads to an understanding of exactly what processes the business performs. 


¢ It provides the ability to analyze existing processes and identify ways to gain efficiencies. 


Technology Element 


If data is the foundation upon which a component-based application rests, technology is the 
infrastructure upon which applications ride, making data available to both users and decision 
makers. Technology can be viewed as the hardware and operating systems allowing applications 
to function. The proper integration of business processes, applications, and infrastructure 1s 
critical to successful information resource management (IRM). For example, analysis of the 
current BEA and indications of target BEA requirements indicate a growing business need to 
integrate automated Geographic Information Systems (GIS) functions within many of the BLM’s 
business processes. 


This requirement, along with the increasing demand for access to more and more data, will 
necessitate significantly greater bandwidth requirements in the BLM target BEA. An analysis of 
those requirements and a knowledge of the applications architecture are needed before specific 
infrastructure design specifications can be determined. If these requirements are not fully 
understood, the probability that the BLM’s infrastructure will collapse under the weight of 
unanticipated demand increases. 


Factors to Be Considered 


There are several important factors that should be considered in making a decision to transition 
to a component-based applications system: 





1. Organizational impact. Component-based applications require a greater degree of data, 
application, and process standardization than currently exists within the BLM. 


to 


Funding impact. Currently, most application development and maintenance is funded by 
individual program offices because the legacy applications they are using were developed to 
support specific program requirements. Under a component-based applications architecture, 
components and applications are more likely to become assets of the entire enterprise instead. 
In the future, either multiple program offices will have to fund development jointly or the 
BLM may want to consider centralized enterprise funding. 


3. Architectural impact. The BLM’s applications architecture will become less complex, more 
reliable, more flexible, and more scalable. Components will become reusable and shared and 
stovepipe applications will gradually become obsolete. Data quality, standardization, and 
accessibility will dramatically improve through use of the EIDS. 


4. Time to market impact. Development time should be dramatically reduced. For example, the 
Military Traffic Management Command experienced a 25 percent reduction in software 
development time after adopting a component-based system. 
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5. Cost impact. Development costs should be dramatically reduced because code for a single 
function such as “name and address” will only have to be developed in a single component 
rather than in every application that needs to access names and addresses. 


Summary 


In conclusion, the concept of a component-based applications architecture provides a vision for 
the future of the BLM’s architecture development. Adoption of the concept will provide strategic 
direction for years to come, enabling the BEA effort to progress with its design of a more 
detailed target environment. It will also provide a focus for information resource management 
efforts regarding data, applications, business processes, and technology. Finally, it will provide 
an opportunity for evolutionary, controlled, and purposeful transition to an environment in which 
information technology becomes a more responsive and efficient tool for supporting the BLM’s 
business requirements. 


D. COMPONENT-BASED APPLICATIONS—SUCCESS STORIES 


The BLM is not an “early adapter” in the area of component-based applications. Therefore, it can 
benefit from the real world “lessons learned” by other organizations that have already had 
experience with reuse, reengineering, and COTS integration. Our challenge is to apply this 
knowledge to the unique BLM environment. Here are some examples: 


¢ Honeywell successfully implemented an award-winning effort on the shop floor of its plant 
in Rocky Mount, North Carolina. A web-based COTS application tracks defects and 
corrective actions. It has not only reduced software costs by 98 percent but also improved 
response times sevenfold. The application also has enabled Honeywell to distribute software 
updates centrally, improving version control. 


¢ NASA’s Jet Propulsion Laboratory successfully built a fully automated, miniaturized antenna 
station using COTS components. As a result, NASA has significantly reduced the cost of 
tracking low-earth-orbit satellites. While no specific cost savings have been provided, the 
NASA research team has emphasized the importance of COTS in not only reducing costs but 
also increasing reliability. 

¢ Hewlett Packard's software reuse guru, Martin Griss, has led several corporate, system-wide 
engineering efforts related to software reuse. While monetary successes have not been 
calculated, forward endeavors have identified the importance of these applications in creating 
a consistent, enterprise-wide methodology. Interestingly, Mr. Griss has not proposed a 
corporate reuse library, given what he identifies as HP’s culture and process maturity, but 
rather, common libraries within unique domains. 


All of our research into “lessons learned” points to several important conclusions: 


¢ Cost benefits from new, custom applications may not be realized for as long as four years, 
emphasizing the need to explore alternative COTS solutions. 


# NASA and Hewlett-Packard, as well as Toshiba, have found that as a rule of thumb, the 
breakeven point is three reuses. 


¢ The support of upper management is critical to the success of the effort. 
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+ Resources available as a result of development/maintenance can be reallocated, resulting in 
enhanced productivity through division of labor. 


The organization's best developers can work on multiple projects simultaneously. 


Knowledge assets are sometimes difficult to value because they are not reflected on 
accounting balance sheets. 
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V. Findings and Recommendations 


A, GENERAL FINDINGS AND RECOMMENDATIONS 


The Federal Enterprise Architecture Framework, 1999, identifies three approaches to developing 
architecture: 


Conventional Approach—Requires a substantial 
initial investment in time and dollars. First, a 
framework must be developed showing how to prepare ee 
an architecture description. Second, the current baseline 
must be described. Finally, a target architecture must be 
described. The implementation of needed architecture 


changes through design, development, and systems Artd f . 

acquisition cannot begin until these activities have been hie tpay — . 

completed. Although this approach appears to be : nen, . Gl , 
a 


_—_—, 








sound, it may result in “paralysis by analysis,” due to 
the complexity of the federal effort. 














Segment Approach—Promotes the incremental 
development of architecture segments within a 
structured enterprise architecture framework. This 
approach focuses on major business areas (e.g., grants 
or common financial systems) and is more likely to 
succeed because the effort is limited to common functions or specific enterprises. 


Status Quo Approach—Represents “business as usual,” resulting in continued failure to share 
information and cope with the rapidly changing environment. This approach would result in 
business rework, decreased productivity, and lost and missed opportunities, as well as failure to 
comply with Clinger-Cohen Act requirements. 


The following two general findings and recommendations relate to the enterprise as a whole and 
are incorporated in lower-level specific recommendations presented in Section V: 


¢ Architecture Approach 


a Finding: The BLM has predominately used the conventional approach to architecture 
development. This has provided a needed framework to identify processes, data, and 
applications. 

a Recommendation: The BLM should build on this framework, consistent with the 
requirements of the Federal EA Framework. Beginning in FY02, the BEA should focus 
on a subset of specific architecture segments, such as LUP, APD, and ROW, for 
incremental, tangible improvements and results. 


The BEA models are corporate assets that can be used, further refined, and decomposed 


by process owners throughout the BLM. They should be encouraged to use these models 
as Starting points for their process improvement and reengineering efforts. Modeling 


29 November 200] 











BLM Enterprise Architecture Version 2.0 Summary Report 


efforts beyond the component areas addressed by the BEA should be integrated into the 
enterprise models to foster the definition and understanding of the BLM’s business. 


As previously mentioned, the BLM has used the Activity-based Costing (ABC) model, 
which consists of nine “cross-cutting” business subject areas. These areas were modeled 
in detail by various subject-matter expert (SME) teams during fiscal years 2000 and 
2001. As these modeling efforts progressed, commonalties across the nine “cross-cutting” 
business subject areas became apparent. At lower layers of detail, similar processes 
appeared across the nine areas, indicating the processes could be restructured to expedite 
analysis from an information architecture perspective. These observations do not negate 
the validity of the ABC model. There will be different perspectives (e.g., cost 
management, information management, customer service, etc.) for analyzing the BLM’s 
business processes. Some models may be more effective than others, depending on the 
viewpoint examined. 


We also found many of the processes across the nine subject areas involved collecting 
and managing information. Planning, Assessment, and Manage Work each had 
subprocesses for collecting and managing information common to each subject area. 
SME participants and BEA team members found another cross-cutting subject area was 
emerging. Thus a new model was defined realigning the nine subject areas into six. This 
model also defined “Collect and Manage Information” as a new business subject area. 
This model has been cross-walked to the ABC model for consistency and traceability. 
Table V.A-1 shows this new subject area in detail. 


fe) | [Toi -laremut-lal-le|-Malielauir-|tels Implement Data Standard 


Ofelale [Vlei mialielaul-lieamereli(-reatlels Determine Implementation Approach 


2.1.1 Determine Information Needs Execute Implementation Plan 












































2.1.2 Determine Information Sources, Interested Parties Maintain Data Standard 
2.1.3 Implement Information Collection Plan 2.2.3.1 | Evaluate Change Requests 
2.1.4 Assemble Information 2.2.3.2 | Evaluate Change Recommendations 
implement Data Management Plan 2.2.3.3 | Revise Data Standard 
Develop Data Standard 2.2.3.4 | Review Revision of Data Standard 
2.2.1.1 | Develop Proposed Standard 2.2.4 Maintain Metadata Repository 
2.2.1.2 | Evaluate Draft Report 2.2.5 Maintain Data Quality 




















2.2.1.3 | Adopt Standard . Conduct Document Management 


Table V.A-1. The “Collect and Manage Information” Subject Area. 








¢ Revised Process Model 

a Finding: Common processes were identified among the nine “cross-cutting” business 
subject areas of the ABC model. 

4 Recommendation: Use the revised model for future information architecture analyses. 
This model will support a more streamlined view of the BLM’s business processes from 
an information management perspective and facilitate business process improvement and 
redesign. 
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B. INDUSTRY/GOVERNMENT EXPERIENCE 


With one exception, all of the recommendations in this report focus on attaining three objectives: 
streamlining processes, improving data quality, and achieving efficiencies in application 
software. As the BLM advances in meeting these objectives, industry and government agencies 
are on the same path—some ahead and some behind. The following section provides a thumbnail 
sketch of organizations that have made significant strides in these areas. They are a source of 
encouragement that BLM is “on the right track” and making wise investments. Additionally, 
they provide a fertile source of proven approaches and lessons-learned. 


Streamlined Processes 


BULL HN Information Systems (Groupe BULL) experienced the following results after 
implementing process improvements: 


¢ Cost savings of at least $1.2 million per year by using inspection software techniques and 
design documentation. 


A 50 percent reduction in code test cycles times. 
A seven- to ten-percent reduction per year in code defects from customers. 


A 4:1 return on investment in the Operating System Development organization by 
implementing Software Process Improvement (SPI) practices. 


(Source: http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr | 3.94.pdf) 
Schlumberger experienced the following results after implementing process improvements: 


¢ A 30 percent increase in overall productivity. 


¢ A nearly 100 percent increase during each six-month period in projects meeting scheduled 
completion because of its process improvement program. 


¢ Dramatically improved quality of process procedures through decreasing defects per 
thousand lines of code by 33 percent. 


¢ A business value factor of 8.8:1 return on investment by implementing software process 
improvements. 


(Source: http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr | 3.94.pdf. ) 
The Oklahoma City Air Logistics Center at Tinker Air Force Base experienced the following 
results after implementing process improvements. This enabled them to avoid rework and 


duplication in their software maintenance evaluation process and maintenance tracking system: 


¢ Estimated savings of more than $4.8 million because of its process improvement activities. 


¢ A business value return ratio of 6.27:1 on the investment in process improvement. 


(Source: http://www.sei.cmu.edu/pub/documents/94.reports/pdt/tr 1 3.94.pdf. ) 
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Improved Data Quality 


The following testimonials speak to the improved data quality enjoyed by other organizations: 


+ 1999 Best Practices in Data Warehousing Awards: Architected Data Mart. Vision 
Service Plan’s challenge was to “provide its customers, comprised of more than 15,000 
groups, with accurate reports of their monthly claims activity” generated from “legacy claims 
systems which had inherent data discrepancies.” The solution was to “implement a group- 
centric claims data warehouse with one view for all its standard claims and an easy-to-use 
front-end reporting tool.” (Source: http://www.dw-institute.com/bp99. htm) 


+ 1999 Best Practices in Data Warehousing Awards: Corporate Data Warehouse. “For 25 
years, data at 3M was fed into 50 business units, while each business unit developed and 
protected its own disparate data mart system and operated as its own company. ...3M could 
not get one view of a customer to understand its purchases across business units ...” Their 
solution was to “realign itself from 50 business units into seven marketing groups, while one 
central repository manages all information globally. 3M eliminated the redundancy of 
leading and managing local and business unit specific DSS systems.” (Source: 
http://www.dw-institute.com/bp99. htm) 


+ 1999 Best Practices in Data Warehousing Awards: Data Extraction. “The IRS required a 
data warehouse that would perform research; provide decision support; and profile and 
provide projections, forecasts, quantitative analysis and modeling in support of IRS's 
business strategies. The IRS used small development teams of one to two people to 
implement nine subject areas/data sets on short development deadlines.” The IRS “developed 
an application architecture to facilitate code generation, handle data conversions and handle 
hierarchical to relational mapping.” The new automated process “now gives the team the 
capability to add three simple last minute data sets and still meet deadlines.” (Source: 
http://www.dw-institute.com/bp99. htm) 


+ 1999 Best Practices in Data Warehousing Awards: Data Quality. The Ohio Department 
of Health (ODH) created a data warehouse in May 1998 that gives easy access to state and 
county summary level public health statistics via the Internet. The ODH has become a much 
better steward of the data they keep as a result of building its data warehouse. The most 
important reason for this was the data standards process that occurred during the 
iraplementation of the warehouse. (Source: http://www.dw-institute.com/bp99. htm) 


+ The US Fish and Wildlife Service is “using data standards to increase the quality and 
compatibility of its data. This approach will increase opportunities to share data and reduce 
incidents of redundant data development. Standards are being developed, reviewed, and 
adopted according to a formal process.” (Source: http://www.fws.gov/stand/) 


¢ Environmental Protection Agency (EPA) Reinventing Environmental Information 
Initiative: “The goals of this initiative are to provide a shared data registry for use by all 
environmental stakeholders, to provide a means for EPA’s partners to participate in 
establishing data standards, and to promote use of data standards throughout the 
environmental protection community. These goals, part of EPA’s overall data management 
program, are critical to supporting effective environmental protection across the U.S. and 
worldwide.” (Source: http://www.epa.gov/rei/about/edr. htm) 
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USDA. USDA Data Repository Working Group Report: The mission of this organization 
is “to build a base of information about data repositories that will help frame alternatives for 
a USDA data repository and potential transition scenarios.” (Source: 
http://www.usda.gov/da/infores/dataman/dmreport.htm) 


Efficiencies in Aplication Software 


The following examples provide proof of the efficiencies in application software: 


° 


C. 


The component approach delivers a system for one-fifth the cost in one-half the time. 
The U.S. Air Force Space and Warning Systems Center (SWSC) delivered its ATAMS in 11 
months rather than the two years anticipated if conventional development techniques had 
been used. Only one post-delivery software error was detected during OT&E. Finally, the 
system was developed by a team of 11 for a total cost of about $2 million, or one fifth of the 
amount estimated if conventional techniques had been used. 


(Source: http://stsc.hill.af.mil/crosstalk/1996/aug/product.asp) 


The component approach improves reuse. Motorola used a component-based approach for 
FLEXworks, a family of one-way pagers. They have shown a four times cycle improvement 
with 80 percent reuse. 


(Source: http://sei.cmu.edu/publications/documents/98.reports/98tr007/98tr007chap02.html) 


The component approach improves productivity. Industry standards for code productivity 
range from 200 to 500 standard lines of code (SLOC) per labor-month. The high levels of 
reuse in some experiences with component software can lead to higher levels of productivity 
ranging from 40 to 400 percent. 


(Source: http://home.stny.rr.com/jeffreypoulin/Papers/CBDchapter0 1 .html) 


The component approach reduces development time. HomeComings Financial Network, 
a subsidiary of GMAC-RFC, used Microsoft's Component Object Model (COM) to develop 
a loan management and reporting capability system. New components can now be built in 
203 weeks. It is estimated they have reduced staff involvement in the process by 20 percent. 
(Source: http://microsoft.com/com/com/cstudy/hcoming.asp) 


SPECIFIC FINDINGS AND RECOMMENDATIONS 


This section of the Summary Report presents specific findings and recommendations stemming 
from the analysis of information collected over the past fiscal year. Information collection 
focused on business processes, data, applications, and technology as discrete entities. Each of our 
20 recommendations is supported by Findings, Recommendations, and Benefits. Table V.C-1 is 
a summary of the BEA Core Team’s recommendations. 
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Target Architecture Element Recommendations 
. Construct EIDS 








. Continue Development of Enterprise Logical Information Model 





l 

2 

3. Perform Data Analysis 
4. Determine Data Costs 

5. Establish Data Standards 











6. Enforce Data Requirements 
Components 7. Implement Legal Entity Component 

8 

9 








. Develop Business Case for Request Management Component 





. Investigate Benefit of a Customer Service Application 





Processes 10. Continue Development of Target Business Process Architecture 
11. Develop the Collect and Manage Information Area 








12. Integrate Geospatial Processing into the BLM Business 





13. Improve Information Sharing in Perform Planning Process 

14. Provide BEA Support to IT-LUP 

15. Implement Corporate Library & Standard Core Process for 
Assessment 

16. Develop Expression of Interest (EOI) (Authorize Use) Checklists 

17. Coordinate Enterprise Document Management Efforts 

















18. Business Process Improvemenv/Transformation 
Technology 19. Plan for Enterprise Infrastructure Upgrades 
Consolidated Architecture 20. Develop BEA Target Enterprise Architecture 




















Table V.C-1. Summary of the BEA Core Team’s Recommendations. 





These 20 individual recommendations are presented within the context of the vision for a 
component-based applications architecture. Each should be considered a stepping-stone or 
building block toward that larger enterprise goal. Attainment of the goal to achieve a component- 
based applications architecture is a multi-year effort, but recommendations implemented over the 
next year will move the BLM closer to it. Some recommendations also are designed to enable the 
BLM to integrate its BEA efforts more tightly with strategic and capital planning. In addition, 
initiatives stemming from this report will influence the development of capital investment plans. 


The specific recommendations that follow focus on enhancements in three program areas—Land 
Use Planning (LUP), Application for Permit Drilling (APD), and Rights of Way (ROW). One 
cross-program area, Expression of Interest (EOI), is the focus of another recommendation. This 
is a segmented approach. The selected program areas closely align with the BLM’s focus on 
energy and minerals and land use plans in the FY02 budget. The BEA Core Team intends to 
establish a close working partnership with the appropriate program offices to provide them with 
extensive assistance in their efforts to improve information technology support in the four 
program areas. Recommendations suggesting improvements in business processes; data quality, 
standardization, and accessibility (through creation of the EIDS); and development of 
appropriate application components relate to all four areas. 
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Enterprise Information Data Store: Findings and Recommendations 


1. Construct Enterprise Information Data Store (EIDS) 








Findings 
@ Analysis of both the BLM Corporate Metadata Repository (CMR) and a data model reverse-engineered from 


national applications indicates a lack of consistency in naming standards for data attributes, entities, tables, 
and columns. 


Quality of data within the BLM is often suspect and content ownership is difficult to determine. 





In many cases, data does not match its intended use, meaning, or reliability. 
There are numerous occurrences of redundant data. 


ee h6 eh h6 OD 


Based on CRUD analysis, there are many instances of the same or similar data being created in more than one 
place (application/process). For example, 64 processes create Case Action data and 17 processes create 
Human Resources data. These are contributing to the problem of redundant and segregated data. 


¢ Data is not managed as an enterprise asset. Design principles have not included common use and reuse. 


Recommendations 








Begin construction of the EIDS, a common BLM data repository. 


Standardize and cleanse data to ensure data quality and eliminate data redundancy. Give priority to 
establishing national data standards supporting the Collect and Manage Information and Perform 
Assessment/Analysis business processes (both alphanumeric and spatial) and Land Use Planning. Migrate 
existing data to corporate enterprise information data stores. 

@ Partner closely with national data stewards responsible for data supporting LUP, APD, EOI, ROW, and 
Request Management to support their efforts to prepare that data for migration to the EIDS. 


Benefits 


There will be an incremental reduction in data redundancy and segregation. 








Common types of information will be shared and reused. 
Data cleansing and standardization will improve data quality. 
Management, protection, accessibility, and use of the data will become an enterprise activity. 


ete? & «6M 


A key element for the component-based applications architecture (including E-GIS Goal), a common data 
repository, will be established. 











‘ne 
ws 


November 2001 





BLM Enterprise Architecture Version 2.0 Summary Report 


2. Continue Development of Enterprise Logical Information Model 








Findings 





¢ In examining existing models (for example, the 1989 Enterprise Data Model, 1991 Enterprise Data Model, 
and ALMRS model), we found data was modeled as defined in each specific application. To support a 
component-based target architecture, a logical data model is necessary. 

¢ There are currently several development projects planned or already underway in which databases are being 
designed and/or implemented (e.g., NILS, LUP, and Fire). Opportunities exist to partner with the program 
organizations currently sponsoring these separate data modeling efforts, support them, and incorporate their 
models into the Enterprise Data Model. 


¢ Data is not currently managed as an enterprise asset designed to be shared and reused. 


Recommendations 








¢ Continue expansion of the Enterprise Logical Data Model (including geospatial objects) based on business 
priorities to include all logical data 

¢ Incorporate other data models, independently developed within the BLM, into the Enterprise Logical Data 
Model. 

¢ Develop a close working partnership with staff performing independent data modeling efforts. Establish 
standard modeling techniques within the BLM and enable independent modeling efforts to take advantage of 
the work already accomplished in the Enterprise Logical Data model. 


Benefits 


Data redundancy and segregation will be minimized. 

The model will provide guidance and standards to determine the architecture appropriate for development of 
future components and applications. 

Quality of data will begin to improve as a result of the consistent application of business rules regarding data. 











Independent modeling efforts will benefit from the work done on the Enterprise Logical Data Model. At the 
same time, the Enterprise Logical Data Model will grow faster from the integration of independent modeling 
efforts of specific functional areas. 








¢ The model will provide the basis for construction of the EIDS. 
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3. Perform Data Analysis 








Findings 





Determination of aspects of data in new projects (Investment Proposals and Business Cases) has not been 
considered in past BLM projects. 





Recommendations 





As part of its review of Investment Proposals and Business Cases, the System Coordination Office (SCO) 
should routinely work with the Project Proponent or Project Manager to produce a custom data impact 
analysis using the CMR tool. The analysis report will tell the Project Manager what types of data are already 
in use, what is available for reuse, what functions can be linked, and what information will have to be 
collected or acquired. 





Benefits 
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The data analysis will place the coor ‘ination of identifying data requirements with the SCO, an organization 
specifically intended to perform this function, thus ensuring architectural appropriateness. 

The identification of possible duplication early in the process will reduce data redundancy. 

The cost of development efforts related to designing databases and applications will be reduced. 

The analysis will encourage the use of the CMR. 

The analysis will help to ensure that any new data design adheres to standards implemented using the products 
of the Data Management Plan. 

The analysis will facilitate the design and use of the Enterprise Information Data Store. 

The analysis will enhance the design of the Enterprise Logical Information Model by allowing new data 
elements to be included quickly. 
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4. Determine Data Costs 








Findings 
¢ Actual data costs for projects have never been determined within the BLM. Data costs could include the costs 


to acquire or collect data, convert data from another platform, maintain data, and ensure data quality. 


Recommendations 











¢ Create a methodology to determine the data costs and benefits. Incorporate the costs and benefits into the 
Return on Investment portion of the Business Case. 


Benefits 


Focuses attention on the up-front and ongoing costs of designing, acquiring, storing, and maintaining data. 
¢ Aids decision-makers such as the Information Technology Investment Board (ITIB) and the Budget 
Committee in being better informed regarding the costs associated with the proposed Business Case. 
¢ Encourages reuse of existing data and applications by requiring Business Case proponents to justify the 
creation of new data and applications. 
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5. Establish Data Standards 








Findings 





The BLM has few Common Data Elements documented or in use. (Common Data Elements are those 
elements that would be used in more than one, and usually in many, applications. They have a standard 
definition, format, and domain set.) Because there are so few documented national standards, every existing 
application uses its own “flavor” of standards and data elements. This results in redundant applications, both 
functionally and with regard to data. 





Recommendations 





Currently, the standardization of two common elements—postal addressing and organizational codes—is 
being pursued. The common elements in the postal area are undergoing final review and the standardization of 
organizational codes has just begun. The BLM has initiated a national task force to officially declare the 
standard and determine the impact on existing applications. 

Many more common elements are needed to promote data reuse and eliminate redundancy. Other areas to be 
targeted soon include land-related elements and elements covering common administrative functions. 
Common Elements will be posted in the Enterprise portion of the CMR. 

New projects should be required to use the standard common elements. An impact analysis on existing 
applications would determine the value of converting to the common element or waiting for the processes in 
the existing application to be re-modeled. 





Benefits 
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Ensures data standards are followed, as described in the Data Management Plan (DMP). 

Facilitates the migration process to the new Enterprise Information Data Store. 

Promotes data reuse to eliminate redundancy. 

Enhances the Enterprise Logical Information Model (ELIM) by identifying candidates for common data 
elements. 

Supports faster implementation of new business initiatives as the portfolio of common data elements designed 
and/or in use grows. 
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6. Enforce Data Requirements 








Findings 





Many automated projects in the BLM have not followed data requirements for the life cycle of the project. 





Recommendations 





SCO Data Management has invested a great deal of effort in determining data requirements throughout the life 
cycle. These requirements have been incorporated into a Best Management Practices for Data in Projects 
document, and State Data Administrators and the Bureau Data Administrator have concurred with them. 
Currently, however, these best management practices are not enforced after the Business Case stage of the life 
cycle. The BLM should be allowed to enforce project management discipline in IT development projects. 





Benefits 
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Ensures new data requirements conform to the BEA. 
Facilitates coordination of data requirements both within and across program lines. 
Encourages project managers to take advantage of “best practices” to deliver robust, business-driven solutions. 


Facilitates the collection and publication of valuable metadata in the CMR by allowing the CMR team to 
require specific metadata for new projects. 


Facilitates the development and use of improved project management skills within the BLM. 

Initiates a formal process (discipline/methodology) for developing business solutions. 

Supports faster implementation of data solutions because “best practices” templates will be in place already. 
Augments “best practices” themselves, promoting continuous process improvement. 
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Components: Findings and Recommendations 





7. Implement Legal Entity Component 





Findings 





¢ Reliance on private data storage in the current legacy applications leads to redundant data entry and makes it 


costly to either understand the “big picture” needs of a single BLM customer, vendor, or interested party, or to 
generalize the needs of customer groups. 

¢ Thirteen national applications write customer data, seven of which write to private data stores. 

¢ Six national applications write employee data, five of which write to private data stores. 

¢ Several more national applications write organization and public data to private data stores. 

¢ The number of state applications writing customer data is unknown. 





Recommendations 





Implement a legal entity component that draws on the legal entity data (information about individuals and 
organizations) in the BEA Enterprise Logical Data Model, along with the business rules associated with that 
data. This component is intended for use by the Customer Service Application recommended elsewhere in this 
document, as well as other applications using legal entity data for customers, interested parties, and vendors. It 
should be similar to the Name and Address investment proposal of the past, but should be scoped and defined 
in the context of a component-based application architecture, and should also provide additional scope and 
guidance from an architectural perspective. 

Ensure the component is sharable and conforms to the Target Architecture. 


Form a partnership with appropriate National Data Stewards to develop Name and Address data standards and 
define the business processes and rules for inclusion in the Legal Entity Component. This will help to ensure 
all requirements are captured. 





Benefits 
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Improves customer satisfaction. 

Improves management of vendors and interested party contacts. 

Reduces risk of litigation due to failure to protect private data. 

Reduces software development and maintenance costs by consolidating legal entity data and data 
management. 

Reduces the time and cost for meeting business objectives through automation. Business objectives may 
include elimination of APD backlog and improved tracking and management of public comments. 
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8. Develop Business Case for Request Management Component 








Findings 
¢ The limited automation of business processes in the Provide Customer Service area results in higher costs for 
customer care and insufficiently accurate tracking and management of customer requests. 





@ Reliance on private data stores in legacy applications leads to redundant data entry and makes it costly to 
understand the “big picture” needs of a single BLM customer or to generalize the needs of customer groups. 
¢ Five national applications write incoming request data, three of which write to private data stores. 

@ Five national applications write response out data, four of which write to private data stores. 


Recommendations 








¢ Build a business case to implement a Request Management Component that supports requests, along with the 
business rules associated with requests, request tracking, and request management. Requests may include: 
customer requests that may eventually become cases or authorizations (e.g., APDs), customer inquiries for 
information and status, and internal requests including those for planning activities and gathering information 
about land and/or resources. This component would be used by the Customer Service Application 
recommended elsewhere in this document, as well other applications creating or processing requests or 
providing request status. 
Focus initially on one or two process areas supporting Customer requests, with possible expansion later. 
Ensure this component is sharable and conforms to the architecture. 


Form a partnership with concerned program area managers to define those business and data requirements 
needed to develop the Request Management Component. This will help to ensure all requirements are 
captured. 





Benefits 


@ Offers greater flexibility in managing workloads at the State, regional, and national levels for tasks that can be 
performed outside of the field office. This will allow operating efficiencies not otherwise available. 





Reduces the risk of violating regulations and policies related to timely response to requests. 
Improves customer satisfaction and makes the customer experience more-consistent. 


Reduces software development and maintenance costs by consolidating request data and request management. 
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Reduces time and costs for meeting business objectives through automation. Business objectives may include 
elimination of APD backlog and improved tracking and management of public comments. 
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Applications: Findings and Recommendations 


9. Develop Business Case for Customer Service Application 


























Findings 

@ No single application exists to support customer care. This increases processing costs and hampers the BLM’s 
ability to provide prompt, consistent service. 

@ Anexcessive number of applications (11) currently support a single process—Process 1.2.2 Research 
Response—within the Provide Customer Service area. 

Three processes from Provide Customer Service have potentially redundant automation. 

Thirteen applications write customer data, seven of which write to private data stores. 

Some processes still use manual methods to service customers. This results in higher costs for customer care 
and insufficiently accurate tracking and management of customer requests. 

@ Process modeling sessions show a recurring theme regarding the need for procedures and automation 
supporting customer contact management. In general, the BLM is unable to provide basic metrics on, or 
tracking of, customer requests from start to finish. There also is a lack of consistency in completing and 
managing requests from customers and information about them. 

Recommendations 

@ Develop a business case for implementing an application that automates processes and business rules 
associated with providing customer service at the BLM. The application should provide for both self-service, 
via the Internet and Public Room access, and full service, in which BLM staff talk directly to customers. 

@ The application should be scoped to include all forms of customer service, from answering simple questions 
and providing documents and forms to checking the status of permits, submitting EOIs of various forms, and 
initiating more substantial requests. 

@ The application should use sharable components fitting the application architecture, including 
recommendations 2 and 3 on pages 36 and 37. 

@ The application should meet the customer service needs of the enterprise rather than being limited to a specific 
geographic or program area. 

Benefits 

@ Improves customer satisfaction. 

@ Reduces the risk of litigation due to inconsistent responses to customers. 

@ Reduces the risk of violating regulations and policies related to customer service. 

@ Reduces time and costs for meeting business objectives and customer expectations through automation. 

@ Reduces software life cycle costs. 
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Processes: Findings and Recommendations 


10. Continue Development of Target Business Process Architecture 








Findi 

@ More than two years ago, the BLM decided to use the high-level business processes from the ABC model as 
the basis for the BEA business process model. The primary purpose of the ABC model is to account for the 
cost of performing all work associated with producing a type of product. This results in an emphasis on cost 
accounting processes that overshadows the importance of business functions. 





@ The ABC model introduces numerous situations in which the same work processes are being performed in 
several ABC areas. 

¢ Core BLM business processes such as “Records Management” and “Collect and Manage Land/Resource 
Information” are not clearly identified in the ABC model and are components of many activities. 

@ The ABC model tends to represent the management and funding of major programs almost as if they were 
separate, and sometimes competing, lines of business. This stove-piping precludes a more logical organization 
of work around common business processes shared by the programs, thereby forcing a high degree of process 
duplication among the programs. Stove-piping of funding strongly encourages stove-piping of applications 
development and duplication of data sets to support the stovepiped applications. 


Recommendations 


@ Use a Business Process Model emphasizing the information structure and common processes rather than the 
cost structure. 








@ Realignment of the ABC-based model processes has already begun. Processes and definitions have been 
drafted but the new model should be reviewed throughout the BLM. 

@ Future work on the target business process model for the BLM should ensure it is comprehensive and captures 
all of the information learned in the earlier work. It will then serve as the basis for identifying future business 
process improvement requirements and for defining the data, applications, and technology required to support 
the requirements. 

@ Inthe future, all architecture business process modeling efforts should be coordinated with the Activity-based 
Costing and Management and Strategic Planning models. This will help to ensure the BLM will be able to 
integrate, or at least cross-connect. these three management views of its business. 


Benefits 


@ Reduces multiple representations of the same work process (as found in the ABC-based modeling done to 
date). 

@ Establishes the foundation for target business processes, from which component architecture 
recommendations can be identified. 








@ Fully integrates the ABC “Sustain Organization” functions, such as IRM and HRM, with basic Line of 
Business work processes. 








@ Captures the business requirement to Collect and Manage Information. 
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1 ie elop the Collect and Manage Information Area 





Findings 

















@ A major portion of the BLM’s business is collecting and managing information related to land, resources, and 
land use. 

@¢ The ABC-based process model does not contain a separate business process area that addresses how the BLM 
collects and manages information. 

@ Analysis of the existing business process model indicates the absence of enterprise-level standard procedures, 
methods, or organization structure to collect and manage information. 

@ The absence of Bureau-wide preferred formats and an organization-wide structure for collecting, managing, 
and sharing data leads to lost time and unnecessary expense. 

Recommendations 

@ Focus further business analysis and modeling on specific business needs and opportunities for the Collect and 

Manage Information component(s). 
Benefits 

@ Provides a common reference to establish clarity and uniformity across information to be collected. 

@ Provides a common mechanism for documenting, understanding, and approving information processing. 

@ Establishes a common repository to ascertain conditions and status information. 

¢ Provides an infrastructure to establish and provide a common set of tools, utilities, and procedures for 
capturing, manipulating, storing, querying, and displaying information. 

@ Provides the ability to recognize duplicate information collection requests. 


Serves as an effective mechanism for identifying redundant cost and resource expenditures. 
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12. Integrate Geospatial Processing into.the BLM Business 





Findings 


@ Since the advent of functional GIS technology, geospatial display, query, and analysis have been automated 
and incorporated into many BLM projects and planning tasks. The benefits of project-based geospatial support 
are significant, but the results tend to be localized within the project and data are not standardized. The 
challenge now is to advance from purely project-based geospatial use to the enterprise-wide integration of 
geospatial tools and data into the work activities of BLM’s resource specialists. This should be done in a way 
that simplifies the sharing of data and geospatial applications and expands that sharing into each business 
process that can benefit from it. Primary responsibility for the task has been assigned to the Enterprise GIS 
Project, with an additional burden assumed by the IT-LUP Project. 


@ The Enterprise GIS (E-GIS) project was established to address these issues, with a focus on making GIS 
technology and spatial data available to resource specialists throughout the BLM. E-GIS is charged with 
creating a geospatial architecture that fits into the overall BEA, while also providing special guidance 
regarding unique geospatial issues for Process, Data, Applications, and Technology (PDAT). The E-GIS 
Project Manager has requested the active assistance of the BEA Team to help his core team: (1) examine the 
BEA business process models and identify geospatial analysis needs and opportunities, and (2) delineate the 
implications of meeting such needs and opportunities with respect to the BEA Enterprise Data Model, 
Applications Architecture, and Technology environment. In this way, E-GIS will begin to identify and 
integrate geospatial functions into the BEA, while also generating specific business support opportunities. 


Recommendations 











Integrate Geospatial Processing into the BLM business. 
The BEA efforts directly assist the Enterprise GIS (E-GIS) project to achieve full integration of geospatial 
information processing into the BLM’s business processes. 

@ The BEA Team should assist the E-GIS Core Team in analyzing existing fifth-level BEA business process 
models to identify specific opportunities for integrating geospatial display, query, and analysis into critical 
work tasks. The BEA Team should also assist the E-GIS Core Team in assessing and anticipating the 
associated requirements for data (Enterprise Information Data Store), applications (NILS, IT-LUP), and 
technology (the Enterprise Architecture Infrastructure Project. with a BEA recommendation concerning 
bandwidth). Finally, the BEA Team should work with E-GIS to define a geospatial architecture comprised of 
fully integrated elements of the Bureau Enterprise Architecture. 


Benefits 


@ Reduces labor requirements for a large majority of the BLM’s business processes by delivering geospatial and 
tabular data, in the form of accurate maps, directly to the desktops of resource specialists. 








@ Helps to ensure that conflicting uses of public lands are not authorized where they would overlap 
geographically and that proposed activities are compliant with LUPs and relevant stipulations. 

@ Supports geospatial analysis and the visualization of results that support better, and easily defended, decisions. 
Integrates geospatial display, query, and analysis into the automated systems used by resource specialists. 
Produces documentation with tables, charts, pictures, video, and maps for resource decisions. 

@ Promotes standardization and accessibility of geospatial data and metadata in support of the IT-LUP project. 
Supports E-Government by providing map-based access to BLM resource data and plans. 
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13. Improve Information Sharing in Perform Planning Process 








Findings 


Processes for implementing and monitoring approved land use plans vary within the BLM. 





Information associated with developing and tracking the LUP varies and is typically stored at the State or field 
level. This results in inefficient reporting at the national level. 

@ Planning is performed in virtually every organization and within virtually every high-level business process 
that was modeled. 

@ There was little consensus on planning activities among participating SMEs or in known documentation 
regarding long-term management responsibility and overall performance/effectiveness of the BLM’s multi- 
year plans (specifically LUP and Facilities plans per modeling to date.) 


Recommendations 


@ Establish national business processes and rules for managing, updating, and tracking land use plans, so the 
LUP becomes a living document. See recommendation | on page 35 for standardizing planning data in 
support of LUP. 


@ Identify automated tools for supporting information sharing. This would include review and support of the 
current business cases relating to LUP as appropriate. 








@ Focus on planning efforts related to Authorize Use areas, such as Application for Permit to Drill and right-of- 
way activities. 





Benefits 


¢ Improves information sharing capability throughout the entire planning life cycle. enabling managers to make 
better business decisions. 





Improves the capability for “what-if” and “changing business conditions” analyses. 
Supports public relations management activities with customers, interested parties, and staff. 








Defines out-year budget and workload requirements. 
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I4. Provide BEA Support to PT-LUP 





Findings 


@ Geospatial processing remains a semi-independent technical support activity in the BLM and has not achieved 
its full potential for streamlining and improving business operations. GIS teams operate mostly as a separate 
group of expert consultants who analyze geospatial data and convert resource data to maps, in response to 
requests from resource specialists. The GIS functionality is not fully integrated into the LUP activity. 


@ The Enterprise GIS (E-GIS) project was established to address issues of this type, with a focus on making GIS 
technology and spatial data available to resource specialists throughout the BLM. E-GIS is charged with 
creating a geospatial architecture that fits into the overall BEA, while also providing special guidance 
regarding unique geospatial issues for Process, Data, Applications, and Technology. The need of the LUP IT 
Support Business Case is similar in that the first area of focus for integration should be the LUP effort 
currently underway. 


@ The Business Case for the IT LUP states: “If the Bureau is to be successful in its current LUP efforts, resource 
specialists must acquire, organize, document, maintain, and professionally analyze information on widely 
ranging topics and then effectively communicate this knowledge to our customers via cutting-edge 
communications and visualization techniques. The BLM’s new planning era, starting in FY 2001, gives us 
both the opportunity and responsibility to evaluate new and existing tools for LUP. Included in this are the 
state-of-the-art geospatial tools needed to implement data standards within the LUP effort.” 


@ Within the Perform Planning process, 17 fourth-level processes involve interfaces with NEPA constituent 
contacts. 








Recommendations 


@ Develop a showcase BEA solution of a business need by direct BEA support of the IT-LUP project. Integrate 
this project with other projects and applications in the selection, control, or evaluation phases. 





@ This recommendation focuses on improving the ability to share information within the planning process and 
providing a mechanism to treat all planning decisions as long-term assets always available to the BLM and 
interested parties. As a part of this recommendation, the potentially automated tools for supporting 
information sharing will/should be identified as defined in the Business Case. This would include review and 
support (as appropriate) to the current business case relating to IT-LUP. The specific role of the BEA Team is 
to communicate and coordinate multiple planning-related project groups, as well as to assist in, and provide 
resources for, process and data modeling efforts. In addition, FY02 efforts should be focused on LUP planning 
efforts related to support Authorize Use areas such as APD and ROW activities. 


¢ Because of the high degree of repetition within a specific subject area, such as the interface with NEPA 
constituents, these processes should be examined for standardization, potential streamlining, and automation 
support (e.g., support from a document management system). 


Benefits 


¢ Improves information access and sharing capability throughout the entire planning life cycle. This results in a 
living LUP instead of one that sits on a shelf. 














¢ Improves the ability to manage expectations and relations with customers, interested parties, and BLM staff. 
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15. Implement Corporate Library & Standard Core Process for Assessment 








Findings 


@ Data used in the assessment process is collected multiple times, in multiple ways and places. In addition, there 
is concern a large amount of other raw data is collected and never included in the assessment process. 





@ Some assessment objectives and questions are not clear. This results in too much data—or the wrong type of 
data—being assessed in some cases. 

@ Several different processes are used to make assessments, primarily because of variances in the questions 
being asked. 

@ Assessments are not performed as efficiently as possible. This is due to a lack of automated tools connected to 
the data needed to support the process (e.g., GIS and statistical packages). 


@ Data from prior assessments is not readily available to support current and future assessments. There is no 
central repository, or library, for completed assessments. 


@ Accurate trend analysis of collected data relative to assessments cannot be performed because of the absence 
of both an adequate assessment information repository and the tools to perform trend analysis. 


@ An increasing number of knowledgeable BLM personnel who define assessment information requirements are 
nearing retirement. Their knowledge will be irretrievably lost if it is not f--mally documented very soon. 


Recommendations 








@ Investigate the feasibility of an enterprise-wide assessment library providing content management and easy 
information retrieval. The focus should start with a specific assessment focus (e.g., LUP assessments). 

@ Implement a core assessment process for all assessment processes and modify it as required for unique 
assessment requirements in different functional areas. Part of the core process should be the implementation of 
standard assessment information needs checklists for various types of assessments. 


@ Design the core process to include the ability to access, retrieve, and store iniitail, derived, and assessment 
results data in order to facilitate trend analysis of the stored data. 

@ Identify potential areas for the reuse and sharing of data that might be included in an assessment component in 
the future. 


@ Focus FYO2 efforts on completing and implementing assessment questions and information checklists related 
to APD, LUP, and ROW. 





Benefits 


Increases the accessibility of assessment information for BLM employees, customers, and decision makers. 





Provides a common set of core assessment questions and information requirements. This will lead to 
consistency in the answers and information provided to similar assessment questions, thereby improving 
customer satisfaction. 
@ Enhances trend analysis capability. This will further augment customer management services by allowing the 
BLM to anticipate customer requests for information and by providing accurate trend analysis to customers. 
@ Standardizes assessment information formats and storage. This will enable the BLM to use the information 
more than once and realize favorable returns on its investment in data collection and maintenance. 
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16. Develop Expression of Interest (EOI) (Authorize Use) Checklists 








Findings 





¢ Current EOI processes lack standardization and adequate automation. Consequently, proponents are not 
always familiar with the types of questions that will be asked or the level of detail and preferred format. 
Standard checklists for each type of EOI are needed. 

¢ The lack of standard checklists can potentially result in inconsistent outcomes, litigation, and customer 
dissatisfaction. 





Recommendations 





¢ Develop and implement checklists by EOI type. Make them available to proponents to help them provide 
appropriate information to the BLM. We recommend two types of checklists at a minimum: 
@ What is expected from the proponent. 
@ What will be considered by the BLM during the EOI decision process. 
Focus FY02 efforts on completing and implementing checklists for EOls related to APD and ROW. 

@ Apply data quality and standards, as outlined in the Data Management Plan, to data on the EOI checklists for 
APD and ROW and migrate that data to the EIDS. 

¢ Develop and implement functionality for supporting Frequently Asked Questions (FAQs) and BLM responses 
relating to the EOI checklists. 

¢ The BEA Core Team should partner with and support the recently approved project “Enhanced AFMSS E- 
Commerce Capabilities for Well Permit and Report Processing” in this endeavor. 


Benefits 


Makes EOI processing faster and more efficient. 








Reduces staff and funding requirements for EOI processing. The will reduce the BLM staff time spent on 
explaining to proponents what is needed and requesting additional basic information and documents required 
for an EOI submission. 

@ Reduces staff and cost requirements for data transformation activities when data storage standards (EIDS) are 
established and provided to proponents 


Improves the satisfaction of EOI proponents. 








Improves the consistency and defensibility of EOI decisions. 
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17. Coordinate Enterprise Document Management Efforts 























Findings 

@ There is a current DOI initiative to evaluate Department requirements for a Document Management System 
within the department. However, the Bureaus within the DOI may be allowed to implement their own 
Document Management Systems. 

@ There are currently several projects assessing Document Management Systems within the BLM. Those 
identified, to date, are: 

@ National Integrated Land System (NILS)—for looking at documents for “land-related” documents such as 
surveys, titles, and case parcels. 

@ Cadastral Survey Field Note System. 

¢ The GLO Project. 

@¢ CACHE & Safety Proposal. 

¢ IT Support for Land-Use Planning. 

¢ Enterprise Information (EI) portal. 

¢ AFMSS. 

¢ Bond & Surety. 

@¢ The BLM needs a bureau-level document management system that will: (1) allow efficient management of 
document creation, receipt. review, sharing, storing, and archiving across the enterprise, and (2) standardize 
forms and data collection methods. In modeling the various types of documents managed by the BLM, we 
found documents and records are managed in many different ways, limiting the ability to share documents and 
records across the BLM. 

Recommendations 

@ Coordinate and consolidate the various document management efforts currently underway within the BLM 
through the System Coordination Office (SCO) and the Architecture Governance process. Ensure the final 
solution is compatible with the component-based architecture. 

¢ Initiate an effort to define the requirements for a BLM Automated Document Management System. 

Benefits 

@ Reduces costs of document management within the BLM by having one system instead of many. 

¢ Improves productivity and interoperability across the BLM from a single system. 

@ Enhances ability to store and retrieve documents and records. 

@ Provides the ability to store documents and records electronically. 
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18. Business Process Improvement/Transformation 





Findings 





¢ The capability of the BEA Team is not being used to its full extent in supporting the BLM decision-making 
process. 





Recommendations 





¢ Offer the BEA Team’s process improvement expertise to the Project Manager/Process Improvement 
prvponent to assist both in the selection phase and as part of the SCO review and feedback. 


Benefits 
¢ Ensures a comprehensive review of all process improvements in three areas: 


@ Other process improvements under consideration. 
@ Alternate process options. 











¢ Application to other similar processes. 
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Technology: Findings and Recommendations 





19. Plan for Enterprise Infrastructure Upgrades 





Findings 


¢ Both trends in applications architecture and the recommendations of the Technical Reference Model strongly 
point toward regional and national sharing of data and applications via web-based architectures. The E- 
Government mandate and projects such as NILS GeoCommunicator, IT Support for Land Use Planning, the 
Enterprise Information Portal, and Enterprise GIS are expecting to add significant, but unknown, new 
demands to the BLM’s Wide Area Network (WAN). 

@ Implementation of BEA recommendations depends on the timely availability of adequate data capacity to both 
BLM offices and external customers. Currently, year-by-year future bandwidth requirements are not known 
and the impact of new proposals is not measured iv terms of their cumulative impact on WAN capacity. 





@ Existing IT architecture guidance presumes that adequate capacity will be obtained. However, new decisions, 
projects, and initiatives are increasing the demand on capacity. 

@ If adequate bandwidth cannot be provided, for any reason, then the BLM will be compelled to delay or reverse 
present architectural trends. Even if the necessary bandwidth can be provided, the issue nevertheless demands 
urgent attention. 





Recommendations 





Plan for adequate enterprise bandwidth. 
Assist project managers in evaluating the bandwidth limits and tradeoffs between bandwidth capacity and 
central/distributed processing. 

@ Monitor bandwidth usage and make policy recommendations to the Chief Information Officer to ensure the 
proper and efficient use of the available bandwidth. 

@ Leverage the existing and approved Enterprise Architecture Infrastructure project in concert with the National 
Operations Center to undertake a BLM-wide bandwidth requirements analysis as soon as possible. The 
analysis should include requirements from all sources, among all organizational tiers, for the next five years. 
The completed requirements analysis should then be included in capital investment planning. 


Benefits 


@ Ensures the information pathways are in place, when needed, to get the full benefit of data sharing, 
applications sharing, remote system management, and the target component architecture. 








Prevents episodic shortfalls of communications capacity. 








Permits E-Government to expand while providing a consistently high level of service to the public. 
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Consolidated Architecture: Findings and Recommendations 


20. Develop BEA Target Enterprise Architecture 








Findings 
¢ Thus far, the BEA effort has been concentrated on the analysis and articulation of the current Enterprise 
Architecture. Specific recommendations are being made in the BEA Version 2.0 Report for changes that will 
begin to shape the target architecture. Future projects should be recommended and implemented only within 
the context of an integrated target enterprise architecture, as stipulated by the Federal Enterprise Architecture 
Framework. Currently only a concept for a target environment has been developed. 


¢ Asthe BEA evolves and matures, it will become an important asset to assist the BLM in proactively guiding 
and coordinating continuous improvement in the organization. 





¢ Within the current organizational structure of the BLM, there is no enterprise-wide organization responsible 
for managing the planning, development, implementation, and maintenance of business processes, data, and 
applications. 

¢ Currently, the BLM is staffing EA tasks as collateral duties for its senior personnel. This limits the speed at 
which EA efforts can progress and be completed. 

¢ The current funding model for information resource investments does not include mechanisms for funding, 
acquiring, and managing shared data, components, and applications. If it is not corrected, this shortcoming 
will be magnified in an architectural environment structured around a component-based applications 
architecture. The BLM will need an enterprise-level organization to manage the development, implementation, 
and maintenance of enterprise components and applications. 

@ Adequate BEA governance is currently lacking. 


Recommendations 








¢ Continue the development of the BEA target enterprise architecture. A concept for the target BEA has been 
presented in this document. Now it is time to add detail and refine that concept. The target BEA should fully 
integrate the process, data, applications, and technology architectures and depict the desired vision of the 
future. 

¢ Identify reusable and shareable components in the target architecture and evaluate proposed projects in light of 
it. 

¢ Formalize the concept of a BEA Core Team by giving it the responsibility for planning, developing, 
implementing, maintaining, and managing the BEA. Provide it with permanent, full-time equivalent staffing. 
The purpose of such an organization should be to provide enterprise-level coordination and integration for all 
EA activities currently being performed at the program level. 


Benefits 


¢ Provides a blueprint for evolution to an environment in which IT will be able to support the BLM’s business 
requirements more eficiently. 








Provide the basis for recommending future IT projects to the ITIB for approval. 
Define future Capital Planning and Investment Control requirements for the BLM as required by the Clinger- 
Cohen Act of 1996. 

@ Greatly strengthen BEA efforts, speeds the BEA development process, and provides dedicated professional 
staff capable of carrying out the increasingly complex and technical task of integrating all aspects of BEA 
development, implementation, maintenance, and management. 
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VI. Transition to a Component-Based Architecture 


A, TRANSITION STRATEGY 


The path to a target architecture is one of evolution, requiring a clear understanding of the 
following: 


# Stated Objective: The design and implementation of a target architecture characterized by a 
component-based applications architecture. 

¢ Required Resources: Approved funding for FY02 BEA projects; applicable business cases 
approved by the ITIB; and human resources such as the BEA Core Team, the SCO, the ITIB, 
project managers and their staffs, and National Data Stewards. 


¢ Implementation Approach: Presented in schedule format in Section VIII. 


These elements are key success factors in ensuring the fruition of the BLM’s vision for a 
component-based applications architecture that will provide automated support for the BLM’s 
business processes. 


B. COMPONENT INTEGRATION 


Smooth transition to a component-based applications architecture will initially require small, 
well-defined steps as the BLM learns the culture of that new environment. Larger, more complex 
and aggressive steps can be taken later, after the transition has achieved initial success and 
everyone is comfortable with the process. 


Figure VI.B-1 graphically depicts most of the recommendations in Section V and their 
relationships to one another. It is not necessary to attempt to implement all of the indicated 
projects or steps during FYO2. 


The chart shows the vision for a component-based applications architecture drives the 
development of the Target BEA. While the Target BEA continues to be developed (see the 
dashed line emanating from “Target BEA”), the concept will drive more immediate projects that 
start the development of the initial components and applications. 


The graphic further illustrates that before a component can be implemented, the business 
processes supported by that component must be transformed to maximize process efficiency. 
Likewise, the data required to support that business process must be modeled according to 
agreed-upon standards and the EIDS must be constructed so the data can then be migrated to the 
EIDS. Once the processes are understood and transformed, as required, to achieve maximum 
efficiency, and the data is migrated to the EIDS, the selected component(s) can be developed. 


Five recommended components are identified. However, it is not necessary to develop them 
simultaneously. Component development will, in turn, lead to the development of new 
applications or the reengineering of legacy applications to take advantage of the new 
components. 
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Dependencies Among the Recommendations 
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Figure VI.B-1. Dependencies Among the Recommendations. 





The BLM should anticipate the transition to a component-based applications architecture will be 
a long process, but also keep in mind the operation of legacy applications can continue 
uninterrupted. Corporations in private industry have found it advantageous to employ COTS 
transitional middleware translators, such as Informatica or PostalSoft, to facilitate the transition. 
Figure V1I.B-2 shows how these translators are used. 


Legacy applications may continue to operate with their existing private data stores. On the other 
hand, bringing new components on line can enhance legacy applications. If reengineered, legacy 
applications can benefit from the same new standardized, quality, accessible data that new 
applications will use. The translator simply makes the new data in the evolving EIDS available to 
the legacy applications. Over time, the EIDS expands, more and more components are deployed, 
and more and more legacy applications are reengineered to use the components. This adds 
flexibility to the applications architecture, reduces development and maintenance costs, and 
greatly increases access to enterprise data. In addition, the translation is transparent to the 
customer. 


The process can be accomplished in the following three phases: 


@ Phase |: Database triggers and/or stored procedures are used to pass data through the 
Translation Layer to cleanse and standardize the data and place it into the EIDS. The 
cleansed data is also stored in the legacy database (planned redundancy). Other applications 
are not yet addressed. (Database Integrity Rules will only permit a single occurrence of the 
name and address to exist in the EIDS. Individual applications are unaware they are using the 
EIDS version.) 
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Figure VI.B-2. Migration to Components with Middleware. 





# Phase 2: The legacy applications that have completed Phase | are modified (one by one) to 
use new components. Other applications begin the migration path described in Phase 1. 
Eventually, all legacy applications use the new component. Application-based private data 
stores cease to exist and the EIDS becomes the primary source of data. The Translation Layer 
will most likely remain necessary to help the architecture evolve as new components are 
developed and applications are reengineered. This approach also facilitates COTS solutions. 


# Phase 3: As new component-based applications are developed, legacy applications are either 
modified to use them or retired when they are no longer needed. 


Adequate architectural governance (the development and implementation of policies and 
procedures to evaluate projects for architecture conformance) enhances the transition to a target 
environment. For example, during the past year, the BEA Team developed criteria that are now 
used to evaluate all business cases for conformance with the BEA. Based on the evaluation, the 
Lead Architect makes an approval/non-approval recommendation to the ITIB. The BEA team 
also integrates its efforts with the SCO’s Select-Control-Evaluate Process for IT projects. 
Implementation of the Data Management Plan is another form of architecture governance. 


Additional requirements for architectural governance will be needed in the future to develop 
policies and procedures related to the efficient development of components for enterprise-wide 
use and the proper integration of data, components, applications, and technology in support of 
business requirements. (See the discussion of Architectural Governance in Section VIL.) 
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VII. Architecture Governance 


For the BEA to improve information management, it must be used as a decision support and 
communication tool to guide IT projects and investments. The BEA facilitates systematic change 
by continually aligning technology investments and projects with the BLM’s mission needs and 
strategic goals. To achieve this end, the BEA is integrated into the BLM’s Information 
Technology Investment Management (ITIM) process via architectural reviews at critical decision 
points. The BLM’s ITIM process is based on the General Accounting Office’s (GAO's) 
“Select—Control—Evaluate” (SCE) methodology. Figure VII-1 illustrates the information and 
process flow methodology. As projects move through each phase, they are evaluated for 
architecture alignment and conformance. The System Coordination Office (SCO) oversees 
national IT projects and investments to ensure adherence with the BLM’s Select, Control, 
Evaluation criteria. 
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Source: Assessing Risks and Returns: A Guide for Evaluating Federal Agencies’ IT Investement Decision-making; 
U.S. General Accounting Office; GAO/AIMD- 10.31.13; February 1997. 


Figure VII-1. Information and Process Flow Methodology. 





Table VII-1 identifies the types of enterprise architecture reviews that should be conducted as 
referenced in A Practical Guide to Federal Enterprise Architecture, February 2001. The BLM 
has established architecture alignment criteria that are used to evaluate proposed business cases 
in the Select phase. Business cases are evaluated against the criteria for all BEA layers (e.g.. 
process, data, applications, and technology) to ensure the proposed project adheres to the 
applicable principles, conceptual target, technical reference model, and other architecture factors. 
For example, to minimize data redundancy and improve or enforce data standardization, 
available data models are reviewed for proposed projects. Systems requiring data already housed 
in existing data stores may be modified to access this data rather than to create redundant data. 
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Type of EA Reviews Review Purpose/Goal 





Business alignment Determine if the proposed project aligns with agency strategic plans, goals, and 
objectives. The goal of the review is to ensure the expected business outcomes of the 
project are aligned to concept and high-level project requirements. 





Business case solution Examine the proposed solution, at a high level, to determine the impact introduced into 
the organization’s IT environment. The goal of the review is to ensure the proposed 
solution supports both the business and technical architecture. 








Sequencing plan Determine whether the proposed investment is consistent with the sequence and 
priorities in the plan. The goal of the review is to ensure progress toward the target 
architecture. 

Technical compliance Determine whether the architecture of the proposed solution complies with the 


enterprise standards, the various architecture levels, and methodologies. The goal of 
this review is to ensure technical compliance of IT projects. 














Source: A Practical Guide to Federal Enterprise Architecture 


Table VII-1. EA Review Goals. 





The results of these reviews are provided to the SCO and the respective project manager or 
proponent. Architecture review results, along with results from other reviews (e.g., financial, 
strategic alignment, and project management), are consolidated and presented to the ITIB for 
consideration in evaluating projects. The ITIB is the BLM executive decision-making body that 
approves or disapproves proposed and ongoing projects and determines whether corrective 
actions should be taken during any of the three SCE phases. 


Projects are evaluated for compliance with the Technical Reference Model (TRM) during the 
Control Phase. These reviews ensure the projects are proceeding along the technical direction 
established by the BLM. Program and Project Leaders should refer to the BEA for guidance and 
constraints on systems architecture and design. A primary goal of the project proponent and 
manager should be to ensure the proposed solution supports the BEA. Figure VII-2 shows that 
the BEA is an iterative process. Standards and technologies are constantly retired, revised, or 
introduced into the architecture for various components (e.g., network or desktop systems). 


The TRM is updated regularly; however, it is a static document. Project reviews must consider 
that although the TRM is static, technology changes are extremely dynamic. A waiver process 
must be established to adequately respond to these situations. Information Management issues 
policy on TRM adherence and provides a waiver process. Non-compliant initiatives may be 
approved for research, concept development, prototyping, and other purposes. These efforts may 
challenge assumptions currently accepted in the EA and may lead ‘» breakthroughs that could 
significantly improve the EA. (See /M 2001-204, Approval and Use of the Information 
Technology TRM, Volume 2.) 


To further architectural governance efforts, the BLM recently established a Technical Review 
Board (TRB). The TRB is chartered to be the governing BLM entity that facilities the ongoing 
development of the Information Technology Architecture (ITA) and determines technical 
conformance to the ITA as defined in the TRM. 
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Figure VII-2. Program/Project Evaluation. 
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VIII. Next Steps 


Focus AREAS 


Table VIII-1 highlights the four functional areas in which recommendations are focused— 
Collect and Manage Information, Assessments, Planning, and Customer Service. It also shows 
the relationship of each of the four areas to the process, data, and application layers of the 
enterprise architecture. For any of the functional areas to evolve to the target environment, 
processes, data, and applications, along with their relationships to each other, must be analyzed 
and restructured. This tables graphically depicts the next set of interdependent activities that are 
the key to the BLM’s success from a business perspective. 








Business 
Subject Area Process Data \pplicatron 
Collect and Manage | Develop new process model | Model data Recommend component 
Information 
Assessments Develop core assessment Build EIDS for assessments | Recommend Components for: 
process emphasizing APD andROW_ | APD 
Modify core for unique Develop data model ROW 
Processes Ensure data quality 
Fully decompose APD and | Migrate data to EIDS 
ROW models 


Identify the data necessary for 
Develop SOP checklist for trend analysis 
APD, ROW, and LUP 








Planning Develop standard processes | Build EIDS for LUP Develop Request Management 
for implementing and tracking | Develop Enterprise Component 
approved LUPs. Information Model Incorporate Request Management 
Ensure data quality Component into Customer Service 
Migrate data to EIDS Application 
Identify shareable planning Recommend component for LUP 
data 
Customer Service Validate Customer Service Build EIDS for Legal Entity | Develop Legal Entity Component 
process model and Request Management Consider Acquiring Customer Service 
Request data model Application 
Ensure data quality model Incorporate Legal Entity and Request 
Migrate data to EIDS Management Components 

















Identify potential new components 


Table VIII-1. Detailed Focus Area Plan. 








INITIAL PLANNING 


Initial-level scheduling considerations for implementing the recommendations presented in 
Section V are depicted in Figure VIII-1. The chart lists the recommendations presented in 
Section V and shows an ideal high-level estimated timeline for completion of each recommended 
p.oject. One major consideration for project commencement is the date on which it is approved 
by the ITIB. Some projects require preliminary staff work on activities such as estimating 
process transformation or data standardization before a business case can be developed and 
submitted to the ITIB for approval. Consequently, the ability of project managers to prepare 
business cases in time for consideration at periodic ITIB meetings is critical. 
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High Level Scheduling Considerations 
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Figure VIII-1. High-Level Scheduling | Considerations. 





BUILDING PARTNERSHIPS 


The BEA team is prepared to support program directors and project managers in any way 
possible to facilitate the preparation of appropriate business cases and the implementation of 
approved projects. The BEA team offers particular expertise in process and data analysis and 
modeling, preparation of data standards, database development, requirements analysis, and 
application analysis. In addition, the BEA team will work with project managers to evaluate the 
implications of BEA requirements and standards for projects and to assist in identifying the most 
expeditious means of meeting those requirements and standards. Efforts over the past two years 
to collect information and establish a baseline current BEA have produced a wealth of 
knowledge about the BLM, its business, and how IT is used to support business requirements. 
The BEA team is eager to share that knowledge and assist program area efforts to more 
efficiently conduct the BLM’s business and share information with its customers. 
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IX. Summary 


This Summary Report has provided an overview of the current BEA and its value to the BLM, 
both as a tool for capital investment planning and for legislative compliance. BLM FY0O1 
initiatives and their accomplishments have been presented here. 


Perhaps the most significant element of this project is its focus on the evolution of the BLM 
Target Architecture. This report presented a Conceptual Target Architecture that will be refined 
with further detail in the coming year. BLM’s Target Architecture will promote robust data 
repositories, also termed enterprise information data stores (EIDS), and will leverage reusable 
application components where practical that are designed to support redefined and streamlined 
business processes. As a first step in this evolution, 20 specific recommendations supporting this 
objective have been identified and an initial implementation schedule has been provided. 


Throughout this report, there is an underlying theme of partnership and teamwork. The ability of 
the Core Team, the BEA Team, and various BLM personnel to come together and produce an 
EA is a testimony to their commitment to this project. This cooperative spirit will, of necessity, 
be a key success factor as enterprise-level decisions are made in following years. 
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Glossary 


Many of the definitions in this glossary have been adapted from The Computer Desktop 
Encyclopedia, Second Edition, by Alan Freedman. New York: AMACOM, 1999. 





Full Name/Definition 







































































ABC Activity-based Costing. 

AFMSS Automated Fluid Minerals Support System. 

ALIS Alaska Land Information System. 

ALMRS Automated Land and Mineral Record System. 

AM Automated Fleet Management System. 

APD Application for Permit to Drill. 

application A specific use of a computer, such as for payroll, inventory, or billing. 

backbone The part of a communications network that handles the major traffic. It 
generally is the fastest transmission path in the network and often covers 
the longest distance of any path as well. 

bandwidth The transmission capability of a communications network. 

BEA BLM Enterprise Architecture. 

BLM Bureau of Land Management. 

BSS Bond and Surety System. 

CBS Collection and Billing System. 

change See configuration management. 

management 

CIO Chief Information Officer. The CIO is generally in charge of all 
information processing within an organization. 

CMR Corporate Metadata Repository. 

component In a component-based architecture, the term means a reusable element of 
an applications architecture that can be used by any application, running 
on any processor in the technology infrastructure, using data available 
from anywhere in the enterprise. 

component- A system for designing application software that incorporates protocols 

based and interfaces for interacting with other programs and providing for 

applications flexibility and expandability to meet future needs. The architecture 

architecture includes small program modules, or components, that are designed to 
work together with each other when an application that uses them is run 
and that allow new applications to be built and customized quickly. 

configuration A system for keeping track of large software development projects. A 

management full-featured system automatically documents all of the components used 
in an application and is able to maintain previous versions of the 
application. 

COTS Commercial-Off-The-Shelf. Ready-made computer hardware or software 

7 that is available for sale. 

CRUD Create, Read, Update, or Delete. 

CRV Common Requirements Vision. A document that provides the basis for the 
development of the Department of the Interior's Enterprise Architecture. 

CSFN Cadastral Survey Field Notes Index System. 
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Acronym/Term Full Name/Definition 


Data Any form of information. In the Information Technology area, the term 
includes such items as spreadsheets, databases, text documents, images, 
and digital voice or video recordings. 

data element The fundamental data structure in a data processing system. Data 
elements are stored in fields. In a customer database, for example, data 
elements might include the customer's name, address, and city. 




















data The management of all data within an organization. This function 

management typically includes administering the data as well as setting the standards 
for how data is defined, perceived, and used. 

data mining Exploring detailed business transactions to uncover patterns and 
relationships within the business activity and history. 

data model A description of a database’s organization, often created as a diagram that 
shows the relationships between entities. 

data processing —_ Using machines to process data. Now called /nformation Technology. 








data repository —_ A database of information about applications software. It may contain 
such fields as author, data elements, inputs, processes, outputs, and 
interrelationships. A repository can also be used to identify software 
components and the business rules for their reuse. 
data storage A permanent or semi-permanent media for storing digital data. Examples 
include magnetic and optical media such as discs and tapes. Not to be 
confused with random access memory, which provides a temporary 
workspace for executing software instructions and processing data. 
data structure The physical layout of data. Examples include data, memo, fixed-length, 
and variable-length fields: database records, files, and indexes; text 
documents, and spreadsheets. 


























DOI Department of the Interior. 
DSA Data subject area. | 
_E-GIS Enterprise GIS. See GIS. 
EA Enterprise Architecture. An Enterprise Architecture is comprised of four 


subordinate architectures: process, data, applications, and technology 
(sometimes called the infrastructure). When fully integrated, they 
represent the EA and describe what the organization does, the information 
required to perform the enterprise's business, the applications used to 
auiomate business processes, and the hardware and operating systems 
used to support the applications. 








EI Enterprise Information. a 
-EIDS se nterprise Information Data Store, 
enterprise An entire organization. — - 





enterprise model A depiction of how an organization conducts its business. The design of 
the organization s information systems is based on this model. 





environment In the case of the BEA, an environment is either the current or target state 
of the EA. The environment describes the status of the processes, data, 
a —__ applications, and technology of the EA. _ 
EOI __ Expression of interest. 
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Acronym/Term Full Name/Definition 








extensibility As applied to a hardware or software system, the term means the 
capability of being easily expanded or customized. See also scalability.. 
FAQ Frequently Asked Questions. An FAQ is a group of commonly asked 


questions about a subject, along with the answers. FAQs are used 
extensively on the Internet. Vendors use them to reduce the need for 
telephone-based customer support. 











FY Fiscal Year. 
GAO General Accounting Office. 
GIS Geographic Information System. GIS is a digital mapping system used for 


exploration, demographics, dispatching, and tracking. 
GLO Project General Land Office Records Automation Project. 




















HR Human Resources. 

HRM Human Resources Management. 

IM Information Management. 

interoperability = The ability of one system to communicate or work with another system. 
IRM Information Resource Management. This discipline analyses an 


organization's information resources. It covers the definitions, uses, value, 
and distribution of all data and information within an organization, and 
evaluates the kinds of data and information an organization requires to 
function and progress effectively. 

IT Information Technology. IT is a broad term covering all aspects of the use 
of computers to process information. Previously known as data 
processing. 

ITIB Information Technology Investment Board. 

LAN Local Area Network. A LAN is a communications network serving users 
within a closely-defined geographic area, such as a single office building. 
It consists of servers, workstations, a network operating system, and 
communications links that tie everything together. 


























legacy An application that has been in existence for some time. 

application | 

legacy system A mainframe- or minicomputer-based information system that has been in 
use for a long time. 

life cycle The useful life of an application or information system. The length of the 


cycle depends on both the nature of the work being done and the software 
development tools used to create it. A large number of patches eventually 
undermines the structural integrity of the system to the point where it can 
no longer be expanded. 




















_LUP Land Use Planning. 7 _ 
MAN Metropolitan Area Network. A MAN 1s a communications network that 
covers a medium-sized geographic area, such as acity or suburb. 
metadata Data that describes other data. A data repository is one example. The term 


may also refer to any file or database that holds information about another 
database's structure, attributes, processing, or changes. _ 








migration A series of steps allowing an organization to evolve smoothly to a new 
Strategy architecture. Also called a migration path. _ 
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Acronym/Term Full Name/Definition 

network A network operating system manages networks as well as the computer 

operating system on which it is installed. It processes multiple requests simultaneously and 
provides the security necessary in a multi-user environment. 

NILS National Integrated Land System. 

OIG Office of the Inspector General. 

operating system The master control program that runs a computer. The operating system 
sets the standards for all of the applications that run on the computer. 

PDAT Process, Data, Applications, and Technology. 

plug and play In the context of software developinent, the term means the ability to add 


a new component and have it work without having to perform any 
technical analysis or procedure. 





program logic 


A sequence of instructions in a program. There are three classes of 
instructions: sequential processing, selection, and iteration. 









































reengineering The use of Information Technology to improve performance and cut 
costs. The technique is used to examine the goals of an organization and 
to redesign its work and business processes from the ground up. 

reusable An existing software component that can be used in building new 

7 applications. 

ROW Right-of-way. 

scalability As applied to a hardware or software system, the term means the 
capability of being easily changed in size and configuration. See also 
extensibility. 

SCO Systems Coordination Office. 

SDE Spatial Database Engine. 

sharable The ability of a software component to be used by more than one 
application. One example is the spell checker in an office applications 
suite, which can be used by all of the applications in the suite. 

SME Subject matter expert. 

stovepipe A standalone application that does not integrate with, or share data or 

application resources with, other applications. 

TCO Total Cost of Ownership. The total cost of using a computer, including the 
hardware, software, upgrades, training, and technical support. 

TRB Technical Review Board. 

TRA. Technical Reference Model. _ 

WAN Wide Area Network. A WAN is a communications network that covers a 


very large geographic area, such as a state or country, 
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